XML BASED SYSTEM FOR UPDATING A DOMAIN MODEL AND 
GENERATING A FORMATTED OUTPUT 

Copyright Statement 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure, as it appears in the Patent Of.fice patent files 
or records, but otherwise reserves all copyrights 
whatsoever . 

Technical Field 

This invention relates, in general, to object oriented 
programming systems, and more particularly to a system for 
updating a domain model and generating a formatted output. 

Background Art 

Hyper Text Markup Language or HTML is synonymous with 
the Internet and the World Wide Web (WWW) . HTML allows 
structural markup of WWW or x Web' documents. XML or 
extensible Markup Language is well known in the >art as a 
document markup language which offers human-readable 
semantic markup and is also machine-readable. As a result, 
XML provides the capability to create, parse and process 
networked data. 
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XML documents are composed of entities, which are 
storage units containing text and/or binary data. Text is 
composed of character streams that form both the document's 
character data content and the document's meta-data markup. 
The markup describes the document's storage layout and 
logical structure. XML also provides a markup mechanism to 
impose constraints on the storage layout and logical 
structure of documents, and it provides mechanisms that can 
be used for strong typing. 

In style and structure, XML documents look quite 
similar to HTML documents. However, when a Web server with 
XML content prepares data for transmission, the Web server 
must generate a context wrapper with each XML fragment, 
including pointers to an associated Document Type Definition 
(DTD) and one or more style sheets for formatting. Clients 
for the Web server that process XML must be able to unpack 
the content fragment, parse the fragment in the context 
according to the DTD (if needed) , render (if needed) in 
accordance with the specified style sheet guidelines, and 
correctly interpret the hypertext semantics (e.g. links) 
associated with each of the different document tags. It is 
understood that a DTD is not required for an XML document, 
instead, the author can simply use an application-specific 
tagset. However, a DTD is useful because it allows 
applications to validate the tagset for proper usage. The 
DTD specifies the set of required and optional elements and 
their attributes for documents to conform to that type. In 
addition, the DTD specifies the names of the tags and the 
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relationships among elements in a document, for example, 
nesting of elements. 

One of the main issues during the development of XML 
was expressing data stored in XML documents into various 
5 formats. This has given rise to the development of 

languages and standards such as XSL and XSLT from W3C. By 
using an XSL style sheet one is able to create an HTML 
representation of an XML document. Similarly, XSL style 
sheets are used to transform XML documents into an HTML 

fq 

10 representation. XSL implementations suffer two principal 

*p limitations. First, XSLT requires the definition of rules 

[0 

12 to transform specific types of XML elements into some other 

%0 type of XML like structure. Although the result may simply 

?~ comprise a stream, the navigation rules must be defined 

CO 15 based on types and the execution of the navigation rules is 
jnj based on the degree of uniqueness of the navigation. In 

B other words, the execution is not a simple procedural 

operation. Secondly, XSLT has no formatting capability 

which means that formatting is performed using flow/format 
20 objects in XSL and is geared towards HTML forming. 

Therefore, the XSL standards fall short for generating code 

or non-*ML output from a data model. 

Another issue is concerned with the transformation of 
XML data. Frequently, XML data needs to be transformed into 
25 another valid XML format. This often comprises an update 
activity not a creation activity. The updates are made to 
specific pre-existing XML data, for example, converting 
selected strings into an alternate format, which is not the 
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same as creating a new document. To be effective, the 
transformation needs to include an efficient navigation 
mechanism. 

Accordingly, there remains a need for a mechanism for 
navigating a data model and extracting specific data from 
the data model. 

Summary of the Invention 



The shortcomings of the prior art are overcome and 
additional advantages are provided through the provision of 
10 a system for updating a domain model and generating a 
formatted output. The system provides two principal 
functions: (a) text format generation from a source data 
model; and (b) manipulation of the DOM tree for the domain 
model . 



" 15 The system provides the capability to navigate a source 

data model and extract specific data from the source data 
model to a target data model. The system utilizes a 
template driven mechanism and directives are provided to 
navigate the source data model and to change the flow of 
20 control of the template. The source data model includes 
read-only data that is extracted and used to generate the 
target data model. Directives are also provided to navigate 
the target data model. 

Through the provision of a set of "structure walking 
25 directives" and a set of basic "string formatting" 
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directives, a user can write a procedural sequence of 
instructions to quickly extract data from a XML source data 
model (e.g. an XML document) and format the extracted data 
into a desired stream for a target data model. The target 
5 data model may comprise a simple ASCII file, or an HTML 

file, or generated content of some other file format. The 
mechanism according to the invention provides a target data 
model without restrictions. 

According to another aspect of the invention, the 
^ 10 mechanism, i.e. directives, is implemented utilizing XML 

cess 

s p thereby providing a language interface which is natural to 

if Hi 

most users. 

L In a first aspect, the present invention provides a 

Co mechanism for manipulating information in a source data 

fli 

J.! 15 model and creating a target data model, the mechanism 

13 includes, (a) a template module having a directive to 

fj, 

manipulate selected data in the source data model; (b) a 
template processing module to process the directive 
contained in the template module; and (c) the template 
20 processing module further includes a component to generate a 
DOM tree for navigating the template module to manipulate 
said source data model. 

In another aspect, the present invention provides a 
method for manipulating selected data in a source data 
25 model, the method comprises the steps of: (a) defining a 

template file having a directive specifying the data to be 
extracted from the source data model; (b) generating a DOM - 
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tree for navigating the template file; and (c) navigating 
the template file and applying the directive to manipulate 
selected data in the source data model. 

In yet another aspect, the present invention provides a 
5 computer program product for an application program for 

creating objects, the application program includes a utility 
for manipulating information in a source data model and 
creating a target data model, the computer program product 
comprises: a recording medium; means recorded on the medium 

10 for instructing a computer to perform the steps of, (a) 

defining a template file having a directive specifying the 
data to be extracted from the source data model; (b) 
generating a DOM tree for navigating the template file; and 
(c) navigating the template file and applying the directive 

15 to manipulate selected data in the source data model. 

Additional features and advantages are realized through 
the techniques of the present invention. Other embodiments 
and aspects of the invention are described in detail herein 
and are considered a part of the claimed invention. 

20 Brief Description of the Drawings 

The subject matter which is regarded as the invention 
is particularly pointed out and distinctly claimed in the 
claims at the conclusion of the specification. The 
foregoing and other objects, features, and advantages of the 
25 invention are apparent from the following detailed 
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description taken in conjunction with the accompanying 
drawings in which: 

FIG. 1 shows in diagrammatic form a system for 
updating a domain model and generating a formatted 
5 output in accordance with the present invention; 

FIG. 2 shows in flowchart form the method 
f ^ steps for processing directives according to the 

%D present invention; 

=F FIG. 3 shows in flowchart form the method 

tj, 10 steps for executing directives according to the 

present invention; 

FIG. 4 shows in flowchart form the method 

t\ \ 

[j steps for resolving a macro according to the 

y present invention; 

. 15 FIG. 5 shows in flowchart form the method 

steps for resolving scoping according to the 
present invention; 

FIG. 6 shows in diagrammatic form a formatted 
output generated according to the present 
20 invention; and 

FIG. 7 shows in diagrammatic form a domain 
model manipulation example according to the 
present invention . 
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Best Mode for Carrying Out the Invention 



Reference is first made to Fig. 1 which shows in 
diagrammatic form a mechanism according to the present 
invention for updating a domain model and generating a 
5 formatted output. The mechanism comprises a template-driven 
implementation. In the preferred embodiment, the mechanism 
is in an application development program for creating 
,?% objects, etc., according to object-oriented principles and 

^ the domain models and trees define an object model. 

10 The mechanism is indicated generally by reference 10 

t[| and comprises a template file or module 12 and a template 

I driven emitter or template processing module 14. As will be 

fg described in more detail below, the template driven emitter 

Vi 14 applies the template file 12 to a domain model 16 to 

□ 15 produce a generated output file 18. In the context of the 
%e * present invention, the domain model 16 comprises a source 

data model and the generated output file 18 comprises a 
target data model. The source data model 16 contains 
read-only data which is extracted by the mechanism 10 and 
20 used to generate a formatted output, i.e. the target data 

model 18. The target data model 18 contains both read/write 
data that is manipulated by the mechanism 10. According to 
the invention, the mechanism 10 provides the capability to 
navigate the data models 16, 18 and also manipulate the 
25 target data model 18. 
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The template file 12 is created as a text file with 
directives that navigate the source data file 16 and 
navigate and manipulate the target data file 18. While the 
mechanism 10 is described in the context of an XML based 
5 data model 16, the mechanism 10 is not concerned with the 
structure of the model 16. The template file 12 is created 
using a conventional editor. The mechanism 10 only responds 
to navigational, substitution and emit directives contained 
in the template files 12. As will be described in more 

"S! 10 detail below, the data model 16 is traversed in a symbolic 

i us 

Eft fashion, i.e. naming the object relationships as strings, 

= S rather than direct object references. The attribute values 

CO are retrieved in the same fashion, i.e. by naming the 

r =" attribute in a string. 

^ 15 In the preferred embodiment, the template file 12 is 

fU expressed in XML format and comprises directives and macros. 

ill 

The specification of the document type definition (DTD) for 
□ the template file 12 is provided below in Appendix I. The 

directives are commands or rules that define the flow of 

20 control. The macros provide for string manipulation. The 
mechanism 10 includes domain model navigation directives, 
domain model manipulation directives, output manipulation 
directives, logical operation directives, and code section 
directives. The domain model navigation directives are used 

25 to navigate the domain model (i.e. the source data model 

16) . The domain model manipulation directives are used to 
modify the domain model (i.e. target data model 18). The 
output manipulation directives are used to modify the 
generated output in the target data model 18. The logical 
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operation directives are used to change the logical 
processing of a template file 12. The code section 
directives are used to maintain code sections in the 
generated output (i.e. target data model 18). A full 
5 listing of the directives is provided below in Appendix II. 

As described above, the source data model (i.e. domain 
model 16 in Fig. 1) contains read-only data that the 
mechanism 10 can extract and use to generate a formatted 
Ir^ output (i.e. the target data model 18). A feature of the 

10 mechanism 10 according to the present invention is the 
_g ability to manipulate the target data model 18. According 

^ to this aspect of the invention, the target data model 18 

irj contains read/write data which can be manipulated according 

5 to directives contained in the template file 12. A full 

m 15 listing of the directives is provided below in Appendix II, 
!H and directives for manipulating the target data model 18 

□ include updatetargetscope, targetscope, addtargetscope, and 

™ remove t a rge t scope . 

The updatetargetscope directive is used to update an 
20 element of a DOM tree associated with a domain model. If 

the element does not exist it is inserted into the DOM tree. 
The syntax for the updatetargetscope directive is shown 
below in Appendix II. The following example describes the 
operation of the updatetargetscope directive: 

25 Suppose the model defines an element "Class 11 which has two 
other embedded elements. This document (i.e the source data 
file 16) is called "class. xml ". 
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class . xml 

<Class name="Set"> 
<Method name="add ff > 
5 </Method> 

<Method name="del"> 

</Method> 

</Class> 

^ 10 Also consider the following template (i.e. template 

m file 12) : 

% <?xml version="l . 0"?> 

CO <!D0CTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 

<_TDEBlock_ DOMTree="class.xml"> 
s 15 <define MACRO=newMethodName>addNew</def ine> 

<targetscope NAME="Method"> 
<updatetargetscope NAME="name" 

TYPE=" ATTRIBUTE ,f >$newMethodName$</updatetarget scope> 
</ targetscope> 
20 </_TDEBlock_> 

The resulting DOM tree when the template is applied to 
the document "class. xml" is as follows: 
<Class name="Set"> 
<Method name="addNew"> 
25 </Method> 

<Method name-"del"> 
</Method> 
</Class> 
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It will be appreciated that the name of the first method 
changes from "add" to "addNew" . 

The targetscope directive is used to navigate to an 
element that is part of an existing DOM tree associated 
with. The syntax for the targetscope directive is described 
below in Appendix II. The following example illustrates the 
operation of the targetscope directive: 

Suppose the model defines an element "Class 11 which has two 
other embedded elements. This document (i.e. the source 
data file 16) is called "class . xml" . 

class . xml 
<Classlist> 
<Class name="Set"> 
<Method name="add"> 
</Method> 

<Method name="del"> 
</Method> 
</Class> 
</Classlist> 

Also consider the following template (i.e. the template file 
12) : 

<?xml version="l . 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd n > 
<_TDEBlock_ DOMTree="class . xml"> 
<targetscope NAME="Class"> 
</targetscope> 
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</_TDEBlock_> 

The template driven emitter 14 navigates to the Class 
element in the class. xml document. It will be understood 
that no emitted output is created since this directive just 
5 navigates the target data model 18 (i.e. the target 

document) . In this case the targeted XML document is 
class . xml . 



The addtargetscope directive is used to insert an 
element into a DOM tree associated with a domain model. The 



Co Suppose the model defines an element w Class 11 which has two 

other embedded elements. This document (i.e. the source 
O 15 data file 16) is called "class. xml". 



h 10 



syntax for the addtargetscope directive is described below 
in Appendix II. The following example illustrates the 
operation of the addtargetscope directive. 



□ 



class . xml 



<Classlist> 



<Class name="Set"> 



<Method name="add M > 



20 



</Method> 



<Method name="del"> 



</Method> 



</Class> 



</Classlist> 



25 



CA919990037US1 



Also consider the following template (i.e. the template file 
12) : 

<?xml version="1.0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 
<_TDEBlock_ DOMTree="class . xml"> 
<targetscope NAME="Class"> 
<addtargetscope NAME="Method"> 

<addtarget scope NAME=" Argument "></ addt ar get scope> 

</addtargetscope> 

< /target scope> 

</_TDEBlock_> 

The resulting DOM tree when the template is applied to the 
document "class. xml" is as follows: 

<ClassList> 

<Class name="Set"> 

<Method> 

<Argument/> 

</Method> 

<Method name="add"> 
</Method> 

<Method name="del"> 
</Method> 
</Class> 
</Classlist> 

The removetargetscope directive is used to delete an 
element from a DOM tree associated with a domain model. The 
syntax for the removetargetscope directive is shown below in 
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Appendix II. The following example describes the operation 
of the removetargetscope directive: 

Suppose the model defines an element "Class 1 ' which has two 
other embedded elements. This document (i.e. the source 
i data file 16) is called "class . xml" . 

class . xml 

<Class name="Set"> 
<Method name="add"> 
yl </Method> 
% 10 <Method name="del"> 

CO </Method> 
In </Class> 

E 

£3 

fg Also consider the following template (i.e. the template file 

[U 12) : 

rn 15 <?xml version="l. 0"?> 

W <!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 

<_TDEBlock_ DOMTree="class . xml"> 
<removetarget scope NAME= "Method" /> 
</_TDEBlock_> 

20 The result of when the template is applied to the document 
"class. xml" is as follows: 

<Class name="Set"> 

<Method name="del"> 

</Method> 
25 </Class> 
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It will be appreciated that the first method element was 
removed. Since no index was specified the default value for 
the index is 0. 



£3 

cn 



It will be appreciated that these directives are very 
useful in applications , such as "Web" applications and 
database applications, which require updating of a model 
stored in XML or a model stored in a database. The other 
directives included in the mechanism 10 according to the 
present invention are described below in Appendix II. 



10 The mechanism 10 also includes XML specific directives 

ffl such as updatetargetdoctype. These XML specific directives 

*2 are for working with data models that are stored as XML 

= (unlike other directives which are not XML data model 

t% specific) . 

fU 

'ti, 15 The updatetargetdoctype directive is used to update the 

C3 ! DOCTYPE element of a DOM tree associated with a domain 

model. If the element does not exist it is inserted into the 

DOM tree. The syntax of the updatetargetdoctype is described 

in Appendix II below. The operation of the 
20 updatetargetdoctype is illustrated by the following example 

which involves adding a simple ! DOCTYPE element (additional 

examples are provided in Appendix II) . 

Consider the following template file: 
<?xml version="l . 0"?> 
25 <! DOCTYPE _TDEBlock_ SYSTEM "../../../.. /dtd/tde . dtd"> 

< TDEBlock > 
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<updatetargetdoctype PUBLIC_NAME="Chemistry // 
PUBLIC_URL="http: //sunsite . unc . edu /public /chemistry . dtd" 
ROOT_ELEMENT_NAME= "myr oot " / > 
</_TDEBlock_> 

The result of when the template is applied is as follows: 
<?xml version="l . 0" standalone="no" ?> 
<!DOCTYPE myroot PUBLIC "Chemistry 11 
"http : //sunsite . unc . edu/public /chemistry . dtd"> 



CM 10 The mechanism 10 according to the present invention 

Jq also includes macro transformations. A macro associates a 

p name with a set of values and enables string substitution. 

i,g within the template file 12. The macro transformations are 

1. useful in situations that require text to be changed to 

O 

fg 15 uppercase, lowercase, truncated, etc. The following macro 
^ transformations are provided in the mechanism 10: toupper, 

£3 tolo^er, truncate, separate, strip, stripTrailing, 



stripLeading, change in_pattern out^pattern, numWords, 
words [i] , and wordfi] . 

20 The toupper macro converts the macro value to all upper 

case letters. If an optional parameter (as described in 

Appendix II) is specified, then only the i'th character is 
converted to upper case. The tolower macro converts the 
macro value to all lower case letters. If the optional 

25 parameter x i' is specified in that case, then only the i'th 
character is converted to lower case. The truncate macro 
truncates the macro value to a specified parameter ^maxlen' 
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characters long by removing vowels. If no maxlen parameter 
is specified, then the macro truncates to the default of 8 
characters. The separate macro separates the values in a 
multivalue macro by separator. If the separator is a 
5 string/character, the separator must be enclosed by quotes 

w . Otherwise it is assumed to be a macro name and the value 
of that macro is used as the separator. It is to be noted 
that when used in a <repeat> statement, repeat blocks are 
separated by a separator. The strip macro removes all 

%Q 10 leading and trailing white space characters from the macro 

*n 

]j* value. If a string pattern is specified (either as a string 

=P or a macro name) , the pattern will be stripped off from the 

ffl 

lJ, macro value. The stripTrailing macro removes all trailing 

white space characters from the macro value. An optional 
fgj 15 pattern to strip may be specified. The stripLeading macro 
^ removes all leading white space characters from the macro 

y value. An optional pattern to strip may be specified. The 

^ change in pattern out pattern macro replaces every 

occurrence of the in_pattern in the macro value with 
20 out_pattern. Strings/characters must be enclosed by quotes, 
otherwise the parameter is assumed to be a macro name and 
the value of that macro will be used. The increment macro 
increments the value of the macro by one. If an optional 
parameter is specified, then the increment step is 

25 defined by . The numWords macro returns the number of 

words in a string. For example, if the string contains "This 
is an apple pie", then the macro numWords returns *5 ? . The 
words [i] macro returns the string after the i'th word 
inclusively. For the previous example, words [3] would 
30 return "an apple pie". The word[i] macro returns the ith 
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word in a string. For the previous example, the macro 
word [3] would return "an". The macro transformations 
included in the mechanism 10 according, to the present 
invention are further described in Appendix II. 

5 According to another aspect, the mechanism 10 utilizes 

a "tree" navigation scheme to perform transformations in the 
source data model 16 (and the target data model 18) . As 
will be described in more detail below, to apply a 
transformation to a node in the data model 16 or 18, the 
Ifi 10 mechanism 10 first navigates the root node for the data 
"J model, then down to the child node until the specific node 

JO of interest is located. Once located, the transformation 

^ rule(s) is applied to the node. As tree navigation is not 

s data model specific, the mechanism 10 according to the 

H 15 present invention is advantageously flexible and can support 
F(J various data model types other than XML. 

□ The mechanism 10 also includes a facility for code 

sections. The code sections are analogous to methods and 
have application for reusing templates, or for overriding 
20 other code sections with the same name. The code sections 
comprise the directives code and call, which are described 
in more detail in Appendix II. 

Reference is next made to Figs. 2 to 5 which show the 
method steps embodied in processing the template file 12 
25 according to the present invention. 
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Fig. 2 shows in flow chart form the method steps 
embodied in'the mechanism 10 for processing directives 
according to the present invention. The method steps 
comprise a process which is indicated generally by reference 
5 100 in Fig. 2. As described above, the directives for 

navigating and/or manipulating the data model are contained 
in the template file 12 (Fig. 1), and the template file 12 
is processed by the template driven emitter 14 (Fig. 1). The 
first step as indicated by block 110 in Fig. 2 involves 
^ 10 initializing the template driven emitter 14, which in the 

Vis 5 

CR preferred embodiment is capable of processing XML documents 

~C and templates. Initialization of the template driven emitter 

14 includes the following operations: creating and 
populating a macro table with predefined macros (which will 
15 be used for string substitution in the template file) and 

creating a code section table (which will be populated with 
code sections, defined by name using the code directive, 
p that will be emitted on the occurrence of a call directive 

using the code sections' name(s)). Additionally, the 
20 template driven emitter generates a DOM tree for the 

template file and for the source data model, both trees used 
for navigating respectively the template file and the source 
data model. DOM or document object model is an API for HTML 
and XML documents established through the W3C Organization. 
25 DOM defines the logical structure of documents and the way a 
document is accessed and manipulated. See 

http://www.w3.org/dom for more information. As used herein, 
DOM trees are understood as used in the context of the DOM 
specification but need strictly follow the DOM 
30 specification. Indeed, as used herein, DOM trees could be 
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trees according to conventional understandings or defined 
according to other non-DOM specifications. 

The next step (block 112) in the process 100 involves 
getting the first or next directive from the template file 
5 12. As described above, the template file 12 is created as 
a text file with the directives specified according to the 
definitions contained in Appendix II. The next step in 
decision block 114 involves ascertaining whether the 
L - J directive is a directive for the template driven emitter 14. 

m 10 (It will be appreciated that only template driven emitter 
directives can drive the operation of the template driven 
uj emitter 14.) If the directive retrieved in step 112 is not a 

\T template driven emitter (TDE) directive, then a check 

s (decision block 128) is made to determine if there any 

H 15 further directives in the template file 12. If no, then the 
U process 100 for processing the template file 12 is 



8 



terminated. If yes, then the next directive in the template 
3 file 12 is retrieved (step 112) and a check is made to 

ascertain if the directive is a TDE directive (decision 
20 block 114) . 



Referring to Fig. 2, if the directive is a TDE 
directive (as determined in decision block 114), then the 
next step (block 116) in the process 100 involves parsing 
the content of the directive for any macros which may be 
25 included. If the content does include a macro value 

(decision block 118) , then a process 300 for resolving the 
macro name is invoked in the block 120. The result of the 
macro name process 300 is a macro value for the macro name 
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The macro name resolving process 300 is described below with 
reference to Fig. 4. As shown in Fig. 2, the next step in 
the process 100 involves determining if the macro value 
returned from the process 300 requires scoping (decision 
5 block 122) . If the macro value requires scoping, then a 

process 400 for scoping the macro value is invoked in block 
130. The macro value scoping process 400 is described in 
more detail below with reference to Fig. 5. Once the macro 
value has been scoped, the directive is executed as 

f 10 indicated by block 124 in Fig. 2. If the macro value does 

0 

p not require scoping as determined in decision block 122, 

p» 

J then the next step is also executing the directive in block 

B 124. If the directive does not contain a macro value as 

l! determined in decision block 118, then processing also 

.Li! 

15 proceeds to executing the directive in block 124. In block 
124, the directive is executed 200 as will be described in 
more detail with reference to Fig. 3 below. The result of 
executing the directive, i.e. content, is written to an 
output buffer as indicated in block 126. Next, a check is 
20 made in decision block 128 to ascertain if there any more 
directives in the template file 12. If there are more 
directives in the template file 12, then the processing 
steps starting at block 112 are repeated as described above. 
If there are no more directives, then the processing of the 
25 template file 12 is completed and the process 100 ends: 



a 



The processing of the template file 12 (Fig. 1) is 
implemented in the template driven emitter 14 (Fig. 1) as 
will be apparent to one skilled in the art based on the 
foregoing description . 
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Reference is next made to Fig. 3, which shows the 
method steps embodied in a process for executing the 
directive as indicated by block 124 (Fig. 2) . As shown in 
Fig. 3, the process for executing the directives is 
5 indicated generally by reference 200. The directives are 
processed according the definitions found in Appendix II. 
The first operation in the process 200 involves pushing the 
current directive context onto a stack as indicated in block 
D 210. Next, the start tag of the directive is processed 

rri 10 (block 212) by, among other things, parsing the directive 
a H and performing the steps required to execute the action of 

the directive in accordance with the relevant definitions 
found in Appendix II. It should be apparent to those 
skilled in the art how to implement the specifications and 
15 definitions of Appendix II. The next operation involves 
fjj determining if the directive contains any ^children' in 

IZ decision block 214. If there is a child, then the current 

O 

p context is set to the child directive in block 216, and 

pushed onto the stack in block 210. The steps in blocks 212 
20 and 214 are repeated in order to navigate the DOM tree. 

Referring to Fig. 3, if the directive does not contain 
a child or any more children (as determined in decision 
block 214), then the end tag of the directive is processed 
in block 218. The last operation in the directive processing 
25 involves popping the current directive context from stack 
(which was pushed in block 210) to restore the state data, 
as indicated in block 220. After this step, the directive 
processing is ended. 



112 
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Reference is next made to Fig. 4 which shows the method 
steps embodied in a process for resolving the macro name as 
indicated by block 120 (Fig. 2). As shown in Fig. 4, the 
process for resolving the macro name is indicated generally 
5 by reference 300. The first step in resolving the macro name 
process 300 involves ascertaining if the macro name is 
stored in the macro table, as indicated by decision block 
310. If the macro name is contained in the macro table, then 

W* the value for the macro name is extracted from the macro 

S3 

m 10 table, as indicated in block 312, and the process 300 is 
s *2 completed. If the macro name is not stored in the macro 

[fl table (decision block 310), then a check is made to 

ascertain if the macro name is stored in the domain model, 
as indicated in decision block 314. If the macro name is 
15 stored in the model, then the value for the macro name is 

extracted from the model, as indicated in block 316, and the 
process 300 for resolving the macro name is completed. If 
the macro name is not stored in the model (as determined in 
decision block 314), then the value for the macro name is 
20 set to the name encased by a y $' character in the template 
file 12. After step 318, the process 300 is completed. 



v3 

£ 

n 



Reference is next made to Fig. 5, which shows the 
method steps embodied in a process for resolving the scoping 
of the macro name as indicated by block 130 (Fig. 2) . As 
25 shown in Fig. 5, the process for resolving the scoping of 
the macro name, i.e. navigating the DOM tree, is indicated 
generally by reference 400. The first step in the process 
400 for resolving the scope of the macro name involves 
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processing the root scope name in block 410. Next, a 
determination is made in decision block 412 to determine if 
the scope refers to a child node in the DOM tree for the 
model. If the scope is a child node, then the scope context 
5 is moved to the child node, as indicated in block 414. After 
step 414, a check is made in decision block 416, to 
determine if the scope name contains any additional scopes. 
If there are additional scopes, then the scope name is 
processed in block 410 and decision block 412 as described 
10 above. 

CP 

J« Referring to Fig. 5, if the scope name does not refer 

5=0 to a child node (as determined in decision block 412), then 

lf% a check is made in decision block 418 to ascertain if the 

scope name refers to a parent node in the DOM tree. If yes, 
ro 15 then the scope context is moved to the parent node as 

indicated in block 420. After this step, a check is made to 
O ascertain if the scope name contains additional scopes in 

decision block 416, as described above. If the scope name 
does not correspond to the parent node (decision block 418), 
20 then a check is made in decision block 422 to determine if 
the scope name refers to the root node in the DOM tree. If 
the scope name refers to the root node, then the scope 
context is moved to the root node, as indicated by block 
424. Next, a check is made in decision block 416 to 
25 determine if the scope name contains additional scopes as 
described above. 
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The operation of the mechanism 10 according to the 
present invention is further described with reference to two 
examples depicted in Fig. 6 and Fig. 7, respectively. 

Reference is made to Fig. 6, which depicts a formatted 
output file 28 generated from a source data file .26 
according to a template file 22. The template file 22 is 
processed according to a template driven emitter 24. The 
arrangement of the template file 22 and the template driven 
emitter 24 are as described above. In operation, the 
template driven emitter 24 reads the source data file 26 and 
creates a DOM tree. The template driven emitter 24 also 
reads the template file 22 and creates a DOM tree (as 
described above) . When the template file 22 is first 
processed, the template driven emitter 24 sets the current 
context to the root element in both DOM trees. Subsequently, 
navigation of the DOM tree is controlled by the scope 
directive (s) contained in the template file 22. As shown in 
Fig. 6, the template file 22 defines the root element as 
'TDEBlock' (Line 3) . In Line 4, the template file 22 
includes a directive which defines .the formatted output file 
28 named by a macro value. Line 6 of the template file 22 
includes a scope directive which changes the context (i.e. 
navigates the DOM tree) to the 'Method' . As shown in Fig. 6, 
the generated output in the output file 28 is indicated by 
'void add ( ) ' in Line 2. The output file 28 is stored under 
the name x Set.java', which was defined by the 'outfile' 
directive in the template file 22 (Line 4). 
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Reference is next made to Fig. 7, which shows an 
example of a DOM tree manipulation according to the present 
invention. As shown in Fig. 7, the template driven emitter 
34 processes a template file 32 which modifies a source data 
5 file 36 to generate an output file 38. The output file 38 

comprises the source file 36 associated with a modified DOM 
tree. As shown in Fig. 7, the template file 32 includes an 
'addtargetscope' directive in Line 4 and another 
'addtargetscope' directive in Line 5. As described above, 
7f 10 the addtargetscope directive is used to insert an element 
CO into the DOM tree. For the template file 32, the first 

K C directive directs the addition of an element called 'Method' 

CO to the DOM tree. The second directive in the template file 

[q 32 directs the addition of an attribute 'name' to the 

s 15 element 'Method' . The element 'Method' with the attribute 

□ 

fQ 'name' appears in Line 7 of the generated output file 38 as 

J«j shown in Fig. 7. It will be appreciated that the data model 

£3 is navigated in a symbolic manner, i.e. naming the object 

relationships as strings, rather than direct object 
20 references. Similarly, the attribute values are retrieved 

by naming the attribute string. 

The detailed descriptions may have been presented in 
terms of program procedures executed on a computer or 
network of computers. These procedural descriptions and 
25 representations are the means used by those skilled in the 
art to most effectively convey the substance of their work 
to others skilled in the art. They may be implemented in 
hardware or software, or a combination of the two. 
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A procedure is here, and generally, conceived to be a 
self-consistent sequence of steps leading to a desired 
result. These steps are those requiring physical 
manipulations of physical quantities. Usually, though not 
5 necessarily, these quantities take the form of electrical or 
magnetic signals capable of being stored, transferred, 
combined, compared, and otherwise manipulated. It proves 
convenient at times, principally for reasons of common 
usage, to refer to these signals as bits, values, elements, 
10 symbols, characters, terms, numbers, objects, attributes or 
the like. It should be noted, however, that all of these and 
similar terms are to be associated with the appropriate 
physical quantities and are merely convenient labels applied 
to these quantities. 



Cdj 15 Further, the manipulations performed are often referred 

fSJ 

jfl to in terms, such as adding or comparing, which are commonly 

O associated with mental operations performed by a human 

operator. No such capability of a human operator is 
necessary, or desirable in most cases, in any of the 
20 operations described herein which form part of the present 
invention; the operations are machine operations. Useful 
machines for performing the operations of the present 
invention include general purpose digital computers or 
similar devices. 

25 Each step of the method may be executed on any general 

computer, such as a mainframe computer, personal computer or 
the like and pursuant to one or more, or a part of one or 
more, program modules or objects generated from any 
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programming language, such as C++, Java, Fortran or the 
like. And still further, each step, or a file or object or 
the like implementing each step, may be executed by special 
purpose hardware or a circuit module designed for that 
5 purpose. 



In the case of diagrams depicted herein, they are 
provided by way of example. There may be variations to these 
diagrams or the steps (or operations) described herein 
1% without departing from the spirit of the invention. For 

£n 10 instance, in certain cases, the steps may be performed in 

pa 

differing order, or steps may be added, deleted or modified. 
All of these variations are considered to comprise part of 
the present invention as recited in the appended claims. 



Q 

ffj Throughout the description and claims of this 

~= =} 

J"** 15 specification, the word "comprise" and variations of the 

Ui 

p word, such as "comprising" and "comprises", is not intended 

^ to exclude other additives, integers or processed steps. 



While the preferred embodiment of this invention has 
been described in relation to the XML language, this 
20 invention need not be solely operate using the XML language. 
It will be apparent to those skilled in the art that the 
invention may equally be operable with other computer 
languages, such as SGML. 

The invention is preferably implemented in a high level 
25 procedural or object-oriented programming language to 
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communicate with a computer. However, the invention can be 
implemented in assembly or machine language, if desired. In 
any case, the language may be a compiled or interpreted 
language . 

While aspects of the invention relate to certain 
computer language and other technological specifications 
(e.g. the XML specification), it should be apparent that 
classes, objects, components, tags and other such software 
and technological items referenced herein need not fully 
conform to the specif ication (s) defined therefor but rather 
may meet only some of the specification requirements. 
Moreover, the classes, objects, components, tags and other 
such software and technological items referenced herein may 
be defined according to equivalent specif ication ( s ) other 
than as indicated herein that provides equivalent or similar 
functionality, constraints, etc. For example, instead of the 
XML language specification, tags and other such software and 
technological items referenced herein may be defined 
according to the SGML specification where applicable and 
appropriate . 

The invention may be implemented as a mechanism or a 
computer program product comprising a recording medium. Such 
a mechanism or computer program product may include, but is 
not limited to, CD-ROMs, diskettes, tapes, hard drives, 
computer RAM or ROM and/or the electronic, magnetic, 
optical, biological or other similar embodiment of the 
program. Indeed, the mechanism or computer program product 
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may include any solid or fluid transmission medium, magnetic 
or optical, or the like, for storing or transmitting signals 
readable by a machine for controlling the operation of a 
general or special purpose programmable computer according 
to the method of the invention and/or to structure its 
components in accordance with a system of the invention. 

The invention may also be implemented in a system. A 

system may comprise a computer that includes a processor and 
a memory device and optionally, a storage device, an output 
device such as a video display and/or an input device such 
as a keyboard or computer mouse. Moreover, a system may 
comprise an interconnected network of computers. Computers 
may equally be in stand-alone form (such as the traditional 
desktop personal computer) or integrated into another 
apparatus (such a cellular telephone) . The system may be 
specially constructed for the required purposes to perform, 
for example, the method steps of the invention or it may 
comprise one or more general purpose computers as 
selectively activated or reconfigured by a computer program 
in accordance with the teachings herein stored in the 
computer (s). The procedures presented herein are not 
inherently related to a particular computer system or other 
apparatus. The required structure for a variety of these 
systems will appear from the description given. 

While this invention has been described in relation to 
preferred embodiments, it will be understood by those 
skilled in the art that changes in the details of 
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construction, arrangement of parts, compositions, processes, 
structures and materials selection may be made without 
departing from the spirit and scope of this invention. Many 
modifications and variations are possible in light of the 
5 above teaching. Thus, it should be understood that the above 
described embodiments have been provided by way of example 
rather than as a limitation and that the specification and 
drawing (s) are, accordingly, to be regarded in an 
illustrative rather than a restrictive sense. 

C5 

5 

^ 10 The present invention can be included in an article of 

=p manufacture (e.g., one or more computer program products) 

rf having, for instance, computer usable media. The media has 

\Q embodied therein, for instance, computer readable program 

JL code means for providing and facilitating the capabilities 

CO 15 of the present invention. The article of manufacture can be 

fU 

) a 1 included as a part of a computer system or sold separately. 

O 

Additionally, at least one program storage device 
readable by a machine, tangibly embodying at least one 
program of instructions executable by the machine to perform 
20 the capabilities of the present invention can be provided. 



The flow diagrams depicted herein are just examples. 
There may be many variations to these diagrams or the steps 
(or operations) described therein without departing from the 
spirit of the invention. For instance, the steps may be 
25 performed in a differing order, or steps may be added, 

deleted or modified. All of these variations are considered 
a part of the claimed invention. 
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Although preferred embodiments have been depicted and 
described in detail herein, it will be apparent to those 
skilled in the relevant art that various modifications, 
additions, substitutions and the like can be made without 
5 departing from the spirit of the invention and these are 

therefore considered to be within the scope of the invention 
as defined in the following claims. 

ft 
=3 

E""3 

0 
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APPENDIX I 



DTD Specifications 



<?xml encoding="US-ASCII"?> 

< ! ENTITY % tdechildren " (# PCDATA | outfile | define | clear 
5 | if | repeat I 

scope | repeatscope | createalias | 

include | code I call | sameline | assert | ifhasscope | 

O 

if hasrepeatscope | hasscope | targetscope )*" > 
^ < ! ENTITY % targettdechildren ,f (#PCDATA I outfile I define | 

T*" 

rC 10 clear | if | repeat | scope I repeatscope | createalias f 
jT include I code | call | sameline | assert | ifhasscope | 

repeattargetscope | 
JU if hasrepeatscope | hasscope | updatetargetscope | 

CO addtargetscope I 

j^j 15 removetargetscope | if hastargetscope I 

C3l if hasrepeattargetscope | hastargetscope | 

□ 

targetscope | updatetargetdoctype )*" > 

<! ENTITY % ifhastdechildren " ( # PCDATA | outfile | define | 
clear | if | else | 
20 repeat I scope | repeatscope I createalias | 

include | code | call I sameline | assert | ifhasscope I 
repeattargetscope | 

ifhasrepeatscope I hasscope I updatetargetscope | 
addtargetscope | 
25 removetargetscope | if hastargetscope I 

if hasrepeattargetscope | hastargetscope | 
targetscope | updatetargetdoctype )*" > 
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<! ENTITY % elsetdechildren 11 (# PC DATA | outfile | define | 

clear | if | repeat I 

scope | repeatscope | createalias I 







include | 


code | call | sameline | assert | ifhasscope | 




5 


if hasrepeatscope I 






hasscope 


else 1 targetscope ) * > 






< ! ELEMENT 


define ( # PC DATA ) > 






< ! ATTLIST 


define MACRO CDATA #REQUIRED> 






<! ELEMENT 


clear EMPTY > 




10 


<! ATTLIST 


clear MACRO CDATA #REQUIRED> 


m 




< ! ELEMENT 


TDEBlock %targettdechildren; > 






<! ATTLIST 


TDEBlock_ DOMTree CDATA #IMPLIED> 






< ! ELEMENT 


updatetargetdoctype EMPTY > 


Is, 
r~ 




<! ATTLIST 


updatetargetdoctype SYSTEM_URL CDATA #IMPLIED> 


%\J 
s 


15 


<! ATTLIST 


updatetargetdoctype PUBLIC_URL CDATA #IMPLIED> 


ffk 

ru 




<! ATTLIST 


updatetargetdoctype PUBLIC_NAME CDATA #IMPLIED> 




<! ATTLIST 


updatetargetdoctype ROOT_ELEMENT_NAME CDATA 



W #IMPLIED> 

q <! ELEMENT if %elsetdechildren; > 

20 <! ATTLIST if EXPRESSION CDATA #REQUIRED> 
<! ELEMENT else EMPTY > 

<! ELEMENT addtarget scope %targettdechildren; > 
<! ATTLIST addtargetscope NAME CDATA #REQUIRED> 
<! ATTLIST addtargetscope TYPE (ELEMENT | ATTRIBUTE) 

25 " ELEMENT "> 

<! ATTLIST addtargetscope INDEX CDATA #IMPLIED > 

<! ELEMENT updatetarget scope %targettdechildren; > 

<! ATTLIST updatetargetscope NAME CDATA #REQUIRED> 

<! ATTLIST updatetargetscope TYPE (ELEMENT | ATTRIBUTE) 

30 " ELEMENT "> 
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< 


! ATTLIST 


updatetargetscope INDEX CDATA #IMPLIED > 






< 


! ELEMENT 


repeattargetscope %targettdechildren; > 






< 


! ATTLIST 


repeattargetscope NAME CDATA #REQUIRED> 






< 


! ELEMENT 


removetargetscope EMPTY > 




5 


< 


! ATTLIST 


removetargetscope NAME CDATA #REQUIRED> 






< 


! ATTLIST 


removetargetscope TYPE (ELEMENT | ATTRIBUTE) 






" ELEMENT "> 






\ 


1 7\ TTT T CT 


rnmAT7£if 2 rrraf ornnQ T l\J Pi T? V Pi Z\ T Z\ #TMDT T TT Pi 
rsIuOVc U aiyS tSCOpc liNDLtA i^U/il/l tr 1 1X1 r L 1 Ej U s 






X. 


1 TTT PMfPMT 


4- —i -y~ /~f £n +- o /— » /~\ v""\ a S' 4~ ^ v* 4- +■ £i /■"■» K i 1 ?~\ v* ^ ■ ^ 

Laigecscope ^ LaigeL LUccniiuj.cn/ ^ 


□ 


10 


y 

s. 


t 2XTTT T QT 
! /i 1 1 L 1 O 1 




I? a- 




/ 

v. 


I 7\ TTT T QT 
! HI 1 LI O 1 


f 3rrraf crnno TMPiETY PPiZlTZi JtTMDT TTTP) S 


===a 

; 




/ 


! ilLEjiYlIMN 1 


IlaoLaigcLbLUpc ^LalLJcLLUcLIlllUIcn/ s 


ffi; 

3 - 




v. 


1 Z\ TTT TQT 


haoi-arrfQf cpnnD Kl ZXMTT 1 PPiZXTZl it P TTPin T P 17 Pi's 


%y 




s. 


1 7\ T'T'T T CT* 
1 L 1 O 1 


K^c.f vAof paa^o TMHI7Y Pi A T Z\ 4TMDT TTTPi "S, 

nas Large us cope unjjejA cjjaih ftinrLiijU 




15 


\ 


1 ITT TTMIT'MT 


linaSLargetscopc ^linasuuccniiuren, ? 


f 






1 7\ T'T'T T CT 


-i fK^cfarrfQfcpAnQ MZ\MT Pi Z\ T Z\ JtPTPOnTPTT'Pl'S 

lrndSLdigeLSCope inhjyiej luaih ffKEjvjuiKrjU^. 








1 7\ TTT T CT 
! /il ILlol 


-i fh^cf 2rnaf oAAnn TNIPiTTY PPlZ\TZ\ # TMDT T TP Pi *S 
lrndSLdigeLSCope INULA UUiilH ff llYitrLlLiL' 


£3 




< 


! ELEMENT 


if has repeat target scope %if hastdechildren; > 






< 


! ATTLIST 


ifhasrepeattargetscope NAME CDATA #REQUIRED> 




20 


< 


! ELEMENT 


repeat %tdechildren; > 






< 


! ATTLIST 


repeat MACRO CDATA #REQUIRED> 






< 


! ELEMENT 


repeatscope %tdechildren; > 






< 


! ATTLIST 


repeatscope NAME CDATA #REQUIRED> 






< 


! ELEMENT 


scope %targettdechildren; > 




25 


< 


! ATTLIST 


scope NAME CDATA #REQUIRED> 






< 


! ELEMENT 


include EMPTY > 






< 


! ATTLIST 


include FILENAME CDATA #REQUIRED> 






< 


! ELEMENT 


outfile %tdechildren; > 






< 


! ATTLIST 


outfile FILENAME CDATA #REQUIRED> 




30 


< 


! ATTLIST 


outfile MODE CDATA #IMPLIED> 
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< 


ELEMENT 


code %tdechildren; > 






< 


ATTLIST 


code NAME CDATA #REQUIRED> 






< 


ELEMENT 


call %tdechildren; > 






< 


ATTLIST 


call NAME CDATA #REQUIRED> 




5 


< 


ATTLIST 


call MACROLIST CDATA #IMPLIED> 






< 


ELEMENT 


sameline %tdechildren; > 






< 


ELEMENT 


assert EMPTY > 






< 


ATTLIST 


assert EXPRESSION CDATA #REQUIRED> 






< 


ELEMENT 


if hasrepeatscope %ifhastdechildren; > 




10 


< 


ATTLIST 


ifhasrepeatscope NAME CDATA #REQUIRED> 


In 




< 


ELEMENT 


hasscope %tdechildren; > 






< 


ATTLIST 


has scope NAME CDATA #REQUIRED> 


.= -=;, 

%y 




< 


ELEMENT 


ifhasscope %if hastdechildren; > 






< 


ATTLIST 


ifhasscope NAME CDATA #REQUIRED> 




15 


< 


ELEMENT 


createalias %targettdechildren; > 


ff| 




< 


ATTLIST 


createalias ALIASNAME CDATA #REQUIRED> 






< 


ATTLIST 


createalias ALIAS PATH CDATA #REQUIRED> 



o 
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APPENDIX II 

Background 

The preferred embodiment of the mechanism according to 
the present invention for updating a domain model and 
5 generating a formatted output works with an XML model, 

however, the mechanism is unaware of the structure of the 
model. It only responds to navigational, substitution and 
emit directives contained in the templates. The model is 
traversed in a symbolic fashion (i.e. naming the object 

: 

10 relationships as strings, rather than direct object 
; — references) , and the attribute values are retrieved in the 

same fashion (i.e. by naming the attribute in a string). 



m 



o 
CO 
fU 



Language Specification 

Introduction 



D 15 For ease of use, the template language is a simple language 

n 

that has a well formed XML syntax. The language consists of 
the following constructs: 

1. Text. Text is emitted as is. Blanks are treated as text; 
any indentation that occurs in the template file will be 

20 echoed in the output. 

2. Macros. Macros associate a name with a set of values. 
They enable string substitution within templates. 

3. Directives. Directives are commands that control code 
generation . 
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4. Comments. Comments help to clarify the template and do 
not get emitted into the output file. 

Throughout this Appendix there are references to the 1 [ ' and 
1 ] ! character. These characters emphasize that the 
5 parameter within these characters are optional. For example 
consider the following: 

transform = toupper [index] 
^ wherein the 'index 1 parameter is optional. 

B £ Template Files 

10 10 Template files are flat text files that are portable across 

f ™ different platforms. They can be edited with any text 

s editor. White space is treated as-is and new line characters 

are expected at the end of each line. In the preferred 
fU embodiment, the template files conform to the XML 

fi! 15 specifications on each platform. 

Macros 

Macros enable string substitution within templates. 

Macros Syntax 
$macro__name$ 

20 Description 

$macro_name$ defines a macro name that will be substituted 
with its assigned string value. The macro instance is 
replaced with the macro value as the output is emitted. A 
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macro name consists of lower and upper case letters, and 
digits . 

A macro is an implicit array: a simple macro has either one 
string value, or a (ordered) sequence of string values; a 
macro structure is either a structure of macro fields 
(which, in turn, are implicit arrays) or it is an array of 
identical structures. Here identical structures is meant to 
imply that all the fields of the structures have the same 
names . 

Example 1 (simple macro) 

Consider the following template definition: 

class $CLASS_NAME$ 
{ 

}; 

If the user defines the macro CLASS_NAME to be GuiObject, 
then the following will be emitted: 

class GuiObject 
{ 

}; 
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Macro Transformations 

Macro transformations allow you to take a macro value, 
convert it to some other form, and then use the result of 
the transformation as the macro value. A transformation can 
5 be used whenever a macro is used. 

Syntax 

$macro_name I transf orm$ 

The first transformation type ( I ) does not permanently 
change the value of the macro, but only during that 
particular macro emit. The second transformation type (=) 
permanently changes the value of the macro. 

The mechanism recognizes the following transformations: 
(note: [parameter] means optional parameter and the user 
must provide an index when using "[ ]") 

transform = toupper [i] | 
tolower [i] | 
truncate [maxlen] | 
separate separator | 
strip [pattern] | 
stripTrailing [pattern] | 
stripLeading [pattern] | 
change in_pattern out_pattern | 
increment [i] I 
numWords | 
words [i] | 
word[i] 
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15 



20 



25 



Description 

The following describes each transform: 

toupper - converts the macro value to all upper case 
letters. If the optional parameter i is specified, then 
5 only the i f th character is converted to upper case. 

tolower - converts the macro value to all lower case 
letters. If the optional parameter i is specified, then 
only the i 1 th character is converted to upper case. 

truncate - truncates the macro value to maxlen 
characters long by removing vowels. With no parameter, 
the default is to truncate to 8 characters. 

separate - separates the values in a multivalue macro 
by a separator. If the separator is a string/character, 
it must be enclosed by quotes w . Otherwise it is 
assumed to be a macro name and the value of that macro 
is used as a separator. When used in a <repeat> 
statement, repeat blocks are separated by a separator. 

strip - removes all leading and trailing white space 
characters from the macro value. If a string pattern is 
20 specified (either as a string or a macro name) , the 

pattern will be stripped off from the macro value. 

stripTrailing - removes all trailing white space 
characters from the macro value. An optional pattern to 
strip can be specified 
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stripLeading - removes all leading white space 
characters from the macro value. An optional pattern to 
strip can be specified. 

change in_pattern out_pattern - replaces every 
5 occurrence of the in_pattern in the macro value with 

the out_pattern. Again, strings/characters must be 
3 enclosed by quotes, else the parameter is assumed to be 

if a macro name and the value of that macro will be used. 

t increment - increments the value of the macro by one. 

& 10 If the optional parameter i is specified, then the 

increment step is i. 

3 

i numWords - returns the number of words of a string. If 

J 

J the string contains "This is an apple pie", numWords 

returns 5. 



15 words [i] - returns the string after the ith word 

inclusively. In the previous example, words [3] would 
return "an apple pie". 



word[i] - returns 
previous example, 

20 Example 1: 

Consider the following 



the ith word in a string. In the 
word[3] would return "an". 

template definition : 



#def ine _$CLASS_NAME | toupper$_HPP 
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/* 

* File name: $CLASS_NAME | truncate$ 
*/ 

If the user defines the macro CLASS_NAME to be GuiObject, 
5 then the following will be emitted: 

#define _GUIOBJECT_HPP_ 

a /* 

vB * File name: GiObject 

S 10 */ 

f'fh 

il Example 2 : 

-3 Consider the following template: 

□ <_TDEBlock_> 

W <def ine MACRO="FILE_NAME">myFile . hpp</def ine> 

IJ 15 <define MACRO="EXTENSION">hpp</def ine> 

9 $FILE NAME | change EXTENSION w cpp ' 1 $ 

O — 

</_TDEBlock_> 

The above template file defines a macro called FILE_NAME 
whose string value is myFile.hpp and EXTENSION is a macro 
20 whose string value is hpp. For information regarding the 
define directive, refer below. The resulting output is 
emitted: 

myFile . cpp 

Example 3: 
25 Consider the following template: 



CA919990037US1 



44 




I 

<_TDEBlock_> 

<def ine MACRO= M first name " > John</ def ine> 
<define MACRO="lastname">Doe</def ine> 
$firstname= touppe'r$ $lastname= toupper$ 
5 $firstname$ $lastname$ 

</_TDEBlock_> 

In this case, the " = ,f transformation type is used instead of 
the "I" transformation type. Note that this template file 
O defines a firstname and lastname macro. The values of the 

in 10 firstname and the lastname macros are uppercased. Once this 
K H is done the values of the firstname and lastname macros are 

[=3 always uppercased. For information regarding the define 

directive, refer below. The resulting output is emitted: 

R JOHN DOE 

fU 15 JOHN DOE 

W 
C3 

□ Note that the values of firstname and lastname macros retain 

their transformation (ie the value of each macro is 
uppercased) . 

Directives 

20 Directives define the flow of control in the template files. 

Directives are enclosed within w < > !l delimiters (e.g. 

<name>) and can appear anywhere in the template. XML 

imposes some restrictions on attribute values. For example 

to form a well-formed XML document the characters '< ! and 

25 '& 1 may only be used to start tags and entities. Therefore, 
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entity references must be used to represent the '< f and 1 &' 
characters. The following is list of entity references: 

Entity Reference Character Representation 
& amp ; & 
5 < < 

> > 
&apos; 1 
&qout; " 

Certain directives must be used in begin/end pairs using the 
10 notation <name> . . . </name>. 

A directive with nothing inside is an empty directive and 
has no effect in the emitted text. If a directive starts in 
the middle of a line, the leading white space is taken as 
indentation for the language and it will not be emitted. 

15 The following directives are supported: 
_TDEBlock_ 
define 
clear 
if 

20 repeat 
scope 

repeatscope 
include 
outfile 
25 code 
call 
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sameline 
assert 
hasscope 
if hasscope 
5 if has repeat scope 

targetscope 
repeat target scope 
if has repeat target scope 
addtar get scope 
£3 10 removetargetscope 
fS updatetarget scope 

= N updat e targe t doc type 

(Q addattribute 

\T updat eat tribute 

%3 

s 15 removeattribute 

addtext 
fy updatetext 

3 _ ;: 

removetext 
O hastargetscope 
20 if hastargetscope 

createalias 

TDEBlock Directive 



_TDEBlock_ is the only required directive that should be 
the root element for each template file. 

25 Syntax 

<_TDEBlock_ SourceDOMTree="sourcedoc. xml" 
TargetDOIMTree= ff targetdoc . xml"> 
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section 
</_TDEBlock_> 

Description 

A source and target XML document can be specified in this 
5 directive. By specifying a target XML document one can 
write directives to modify the targeted XML document. By 
specifying a source XML document one can read data from the 
XML document. For more information see the "Modifying 
Existing DOM Trees" section. 

^ 10 Example 1: Simple template file 
=F <_TDEBlock_> 
rf </ TDEBlock > 

= 

f=l Example 2: Simple template file that specifies a target XML 

[3 document 

Ld 15 <_TDEBlock_ TargetDOMTree="doc . xml"> 
O </_TDEBlock_> 

Example 3: Simple template file that specifies a target XML 
document and a source XML document. 
<_TDEBlock_ SourceDOMTree="sourcedoc . xml" 
20 TargetDOMTree="doc . xml"> 
</_TDEBlock_> 

define Directive 
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The define directive associates the specified value, 
macro_value, with the macro_name. NOTE: <define> can only 
be used to define simple macros. \ 
Syntax 

<def ine MACRO="macro_name [ I 
transformation] ">value</def ine> 

Description 

The define directive takes a single macro_value and assigns 
it to macro_name. The macro_value will be interpreted as is. 
If a transformation is present, macro_value is transformed 
before being assigned to macro_name. Multiple values can be 
assigned to macro_name by performing subsequent definitions. 
For macros that have multiple value assignments, the values 
are concatenated together (without separators) and treated 
as a single string. See below for multi-valued macros usage 
in a repeat directive. The macro definition can be removed 
by the clear directive. 

NOTE: 

<def ine MACRO="MACRO">value</def ine> 
is different from 
<define MACRO=" MACRO "> 
value 
</def ine> 

as an extra newline character. is added by the later. 

Example 1: Single-value macro 

Consider the following template definition: 

< TDEBlock > 
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<define MACRO="String n > 
Hi there. \ 
How are you? 
</def ine> 
5 $String$ 

</ TDEBlock > 



The resulting output emitted is: 



f3 Hi there. How are you? 



10 The backslash at the end of the first line prevents the end 

=F of line character from being embedded in the string. If "V 

[7 is omitted, the text will be emitted on two lines as is. 

□ Example 2: Multi-value macro 

^ Consider the following template definition: 

fll 

y 15 <_TDEBlock__> 

^3 <define MACR0="T Class">Parent </define> 



<def ine MACRO="T_Class M >Class</def ine> 
<def ine MACRO="M_Class">my_class</def ine> 
class $M_Class$ : public $T_Class$ 
20 { 

ARG 

}; 

</ TDEBlock > 



When you run the TDE, the following is emitted: 

25 

class my_class : public Parent_Class 
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{ 

ARG 

}; 

Example 3: Transformation applied to macros 
5 Consider the following template definition: 
<?xml version= M 1.0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "../../.. /tde . dtd"> 
<_TDEBlock_> 

□ <outfile FILENAME=" define . log"> 

^ 10 <define MACRO="macrol I toupper | strip E">one</def ine> 

s g <define MACRO="macro2 I tolower | strip E">one</def ine> 

"fc <define MACRO="macro3 | tolower | strip e">ONE</def ine> 

U3 

j>« $macrol$ 
$macro2$ 

□ 15 $macro3$ 

«1 </outfile> 
?y 

W <_TDEBlock_> 

f ^ 

The following is emitted to the "define.log" file: 
ON 

20 one 
on 

The above template file defines a macro called "macrol" that 
goes through two transforms. The first transform uppercases 
the value of this macro, in this case the value changes from 
25 "one" to "ONE". After that transformation, the "E" is 

stripped from the end. The resulting macro is "ON". The 
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second macro also goes through two transforms. The first 
transform lowercases the macro value from "one" to "one". 
In this case though this transform is meaningless since the 
macro value is already lower. After the tolower transform, 
an "E" character is stripped from the end. Note that this 
transform will fail since the "strip" transform is looking 
for a capital "E" character and the value of the macro is 
all lowercased. Therefore, the resulting macro value is 
"one". The last macro - macro3 - also goes through two 
transforms. The first transform lowercases the macro value 
from "ONE" to "one". The second transform strips the "e" 
character from the macro value. Note that at this point 
the macro value is all lowercased, therefore the resulting 
macro value will be "on". 



Directive 

lear directive is used to clear the value for the macro 
iated with the macro_name supplied. 

Syntax 

<clear MACRO="macro-list "> 
where, 

macro-list = macro name [, macro-list ] 



Description 

This directive is useful for changing the value of a 
macro_name, rather than adding to it 

(as the define directive does) . Using a macro__name that has 
been previously cleared has the same effect as using a 
macro name that has never been defined. Furthermore, 
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issuing a clear on a macro which has not been defined has no 
effect . 

Example 

The following clears the macro MEMBER_NAME. 
5 <_TDEBlock_> 

<def ine MACRO- "MEMBER__NAME">f oo</def ine> 
<clear MACRO- " MEMBER_NAME " > 
$MEMBER_NAME$ 
n| </_TDEBlock_> 

cn 

%* 10 The resulting emitted output is as follows: 
=P $MEMBER_NAME$ 

5 ; 3 
?" ! 

The macro MEMBER_NAME has a value of "foo" then it is 
#3 cleared. When the macro is 

cleared it is as though the macro was never defined, 
y 15 Therefore the generated output would print out the macro 

Q name instead of the value (i.e. $MEMBER NAME$) . 

□ 

if Directive 

The if directive facilitates the emission of a section of 
code based on some condition ( s ) . The syntax used for 
20 filtering is similar to that used for conditional branches 
in C, 

Syntax 

<if EXPRESSION= T, expr"> 
<else/> 
25 </if> 
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ffl 

! - 



L_3 



uj 



where, 

expr= (expr logical-operator expr) 
(value cond value) 
( $macro_name$ ) 
5 ( ! expr) 

( ! $macro_name$) 
logical-operator = & | | 
cond = == I != I < I > I <= I >= 
value = string | $macro_name$ 

10 Description 

The conditional expression must be fully parenthesized. An 
expression takes the form of a value, followed by a 
condition, then followed by a value. The value can be a 
string or another macro_name. The expression evaluates to a 

15 string comparison. The else clause is optional. If the 

expression is too long, you can use the w \ ,f as an escape 
character to specify it on multiple lines. The ! is used as 
a negation operator. If strings contain blanks they can be 
enclosed by quotes. The < s and > f operators are used for 

20 string containment: A < B evaluates to true if A is a 

substring of B (e.g. SI < S2 evaluates if SI is a substring 
of S2. ) On the other hand, '<=' and '>=' have a different 
interpretation compared to 1 <' and ! > ! . 1 <=' and ! >=' are 
relational operators used for comparing expressions, (e.g 

25 (value <=1) evaluates if value is smaller or equal to 1.) 

Example #1 

This example illustrates the use of nested ifs: 
< TDEBlock > 
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<if EXPRESSION=" ( $METHOD_NAME$ == &qout ; queue&qout ; ) "> 
code to emit if method name is w queue 11 
<else/Xif EXPRESSION^' ($METHOD_NAME$ == 
&qout;print&qout ; ) "> 
5 code to emit if method name is w print 11 

<else/> 

code to emit otherwise... 
</if></if> 
</_TDEBlock_> 

10 Example #2 

This example illustrates the use of the less-than (<) 
operation and the and (&) operation. The conditional 
operators act on string values. 



B <_TDEBlock_> 

m 

15 <outfile FILENAME="if . log"> 
W <define MACRO="TotalMethods"> print delete add </define> 

^ <define MACRO="MY_METHOD">print</def ine> 

<define MACRO="DONE">no</def ine> 

<if EXPRESSION^' ( ( ! ($MY_METHOD$ < $TotalMethods$ ) ) & 
20 ( $DONE$ != &qout;yes&qout; ) ) "> 

code to emit if we're not done and my method is 
unknown 
</if> 

</outf ile> 
25 </ TDEBlock > 



The emitted code is as follows: 
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code to emit if we're not done and my method is 
unknown 



Since the MY_METHOD macro is a substring of TotalMethods and 
the DONE macro is not equal to "yes" the section of text 
5 within the if statement is emitted. 



Example #3 

This example illustrates the use of a single macro_name: 
n <_TDEBlock_> 

V3 <if EXPRESSION^" ($MEMBER$) "> 

10 code to emit if member has a value 

*p </if> 
[Jj </_TDEBlock_> 

^3 No code is emitted since the MEMBER macro is not defined. 



CO repeat Directive 

lj 15 The repeat directive allows a single section of a template 
O to emit over and over again on multivalue macro. It acts as 

a macro iterator. 



Syntax 

<repeat MACRO="macro-list [ | transformation] "> 
20 section 

</repeat> 
where 

macro-list = macro name [, macro-list ] 



Description 
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The repeat directive will emit a section, within the start 
and end delimiters, repeatedly for each value associated 
with macro_name. The macro-list defines which macros to 
iterate over. If a macro has multiple values, each value 
5 will be emitted once in the repeat section. In essence, the 
repeat is analogous to a for loop, looping through all the 
macro values. If a transformation is present, it applies to 
the text contained within the repeat section. The number of 
iterations is the smallest number of values the macros have. 
O 10 If one of the macros is undefined, the code inside the 



fi 



<repeat> 



</repeat> will not be emitted. 



Example 1 

Consider the following template definition: 



< TDEBlock > 



□ 15 



<def ine MACRO="COUNT">K/def ine> 



<def ine MACR0="C0UNT">2</def ine> 



<def ine MACR0="C0UNT">3</def ine> 



20 



<repeat MACRO="COUNT"> 
list . add (person$COUNT$ ) ; 
</repeat> 



</ TDEBlock > 



When the template is parsed, the following is emitted: 



25 



list . add (personl) ; 
list . add (person2 ) ; 
list . add (person3) ; 



Example 2 

Consider the following template definition: 
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<_TDEBlock_> 

<define MACRO="TYPE">int</def ine> 
<def ine MACRO="TYPE">char</def ine> 
<def ine MACRO="FUNC">print</def ine> 
5 <define MACRO="FUNC">display</def ine> 

<repeat MACRO="TYPE, FUNC"> 
void $FUNC$ ($TYPE$ x) ; 
</repeat> 
</_TDEBlock_> 

10 When the template is parsed, the following is emitted: 
^ void print (int x) ; 

*F void display (char x) ; 

L-i. 

Example 3 

q Consider the following template definition 

W 15 < TDEBlock > 

fil _ _ 

<define MACRO="TYPE">int</def ine> 



<define MACRO="TYPE">char</def ine> 
<define MACRO- " PARAM " > i < / de f i ne > 
<define MACRO " PARAM" >c</define> 
20 void f unc ( 

<repeat MACRO "TYPE, PARAM | separate *','"» > 
$TYPE$ $ PARAM $ 

</repeat> 
) ; 

25 </_TDEBlock_> 

When the template is parsed, the following is emitted: 
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void f unc ( 

int i f 
char c 
) ; 

5 scope Directive 

The scope directive is used to navigate the XML model and 
specify how the macros in a section are scoped. 

Syntax 

O <scope NAME="sname"> 

t Hi 

m 10 section 
</scope> 

Description 

The sname specifies the name of the scope. 
Example 

15 Suppose the model defines an element '' Class' ' which has two 
other embedded elements. 

<Class name="Set"> 
<Method name="add"> 
20 </Method> 
</Class> 

When the element w Class' 1 is generated, using the following 
template : 

25 < TDEBlock > 
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class $name$ { <-- this $name$ is from the Class 

obj ect 

<scope NAME="Method"> 
void $name$ ( ) ; 

</scope> 

}; 

</_TDEBlock_> 

this will be emitted as: 

class Set { 

void add ( ) ; 

} 

In order to make scoping conceptually easy to use, a 
'directory* navigation approach has been adopted. By 
specifying a ! // ? an implicit scope operation is implied. 
For example, consider the following XML document. 

<classlist> 

<class classname= n MyClass"> 

< da t amemb e r >Memb e r 1< / da t amembe r > 

</class> 
</classlist> 

And the following template file: 

<_TDEBlock__> 

<scope NAME="class"> 

<scope NAME="datamember"> 
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</scope> 
</scope> 
</ TDEBlock > 



The above template file can also be written as: 

5 

<_TDEBlock_> 

<scope NAME=" class/ /da tamember"> 

</scope> 

</_TDEBlock_> 

in 10 It is also possible to write a template without using the 
= p scope directive. Consider the following XML document. 

£0 

^ <Class name="Set"> 

s <Method name="add"> 

}fs </Method> 
fU 15 </Class> 

f ^ 

P Also consider the following template file. 

<_TDEBlock_> 

class $name$ { <-- this $name$ is from the Class 

ob j ect 

20 void $Method//name$ () ; 

}; 

</_TDEBlock_> 

The following is the resulting emitted code: 
class Set { 



CA919990037US1 



\0 



W 15 

□ 
□ 



void add ( ) ; 



The scoping navigation starts at the current scope. 
However, navigation can occur relative to the root element 
5 by specifying a f //' in front of the scoping pattern. 

Parent navigation can also be achieved by specifying 1 . . ' 
within the scoping pattern. Consider the following XML 
document . 

£3 

^ <classlist> 

y 3 

-£ 10 <class classname="MyClass"> 

^ <datamember>Memberl</datamember> 

m 

M> </class> 
</classlist> 



And, the following template file, 



<_TDEBlock_> 
<scope NAME="class"> 

<scope NAME="datamember "> 
<scope NAME=" . . "> 
20 $classname$ 

</scope> 
</scope> 
</scope> 
</_TDEBlock_> 

25 The following would be emitted: 

MyClass 
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An XML document can consists of elements of the same type. 
In order to navigate elements of the same type an index is 
specified to represent a specific element. For example the 
following XML document consists of three elements of the 
5 same type. 



<classlist> 
<class> 

<method>init</method> 
10 <method>read</method> 
<method>write</method> 
</class> 
</classlist> 



Scoping can occur based on the position of the element. 
15 This is illustrated in the following template file. 

<_TDEBlock_> 

<scope NAME="class"> 

<scope NAME="method[l] "> 
$TEXT$ 
20 </scope> 

<scope NAME= ,f method[2] "> 

$TEXT$ 
</scope> 

<scope NAME="method[0] "> 
25 $TEXT$ 
</scope> 
</ scope> 
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</_TDEBlock_> 

The following would be emitted: 
read 

5 write 

init 

repeat scope Directive 
□ The repeatscope directive allows a single section of a 

m 10 template to emit over and over again on a list of elements. 
=p It acts as an element iterator. 

Syntax 

• Hi 

7\ <repeat scope NAME="sname" SEPARATOR= ,f separator 11 > 

?3 section 

ry 15 </repeatscope> 

l . 3 , 

*jf Description 

fg The sname specifies the name of the scope. The separator 

specifies the delimiter to use between sections. The 
default value is an empty string. 

20 Example 1 

Suppose the model defines an element 11 Class 11 which has two 
other embedded elements. 

<Classlist> 
25 <Class name="Set"> 
<Method name="add"> 
</Method> 
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<Method name="del"> 
</Method> 
</Class> 
</Classlist> 

5 When the element 11 Class 1 1 is generated, using the 
following template: 

<_TDEBlock_> 
<scope NAME="Class"> 
■ifli 10 <repeatscope NAME="Method"> 



CO 15 The following would be emitted. 
!H add 
□ del 

Example 2 

Consider the following XML document. This example shows how 
20 one can use the 1 SEPARATOR 1 attribute. 

<Elementlist> 
<Element name= n A"/> 
<Element name="B"/> 
<Element name="C'7> 
25 <Element name="D"/> 
<Element name="E"/> 



$name$ 



< /repeat scope> 
</scope> 
</ TDEBlock > 
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<Element name="F"/> 
<Element name="G"/> 
</Elementlist> 

And, the following template file. 
5 <_TDEBlock_> 

<repeatscope NAME=" Element " SEPARATOR^" , " > 
$name$ 

</ repeat scope> 
r\ </_TDEBlock_> 
\D 

j* 10 The resulting emitted code is as follows: 
=P A, B,C, D, E, F,G 

m 

^ include directive 

□ The include directive imbeds a single input template file 

^ 15 in-line. 

ru 

W 
*==, 

~ Syntax 

<include FILENAME= M input_f ile_name"/> 

Description 

The include directive includes an entire file specified by 
20 input_f ile_name f into the input stream for processing. It is 
analogous to the #include file_name C directive. The 
input_f ile_name must be an input template file. 

Example 

A file called comment. tde contains the following: 

25 
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// 

// C++ Generated Code 

// 

Consider the following template file which includes 
5 comment . tde : 

<_TDEBlock_> 

<include FILENAME=" comment . tde"/> 
class A { } ; 

C3 

i.O 10 </_TDEBlock_> 

in 

B g The following is emitted: 

CO 



// C++ Generated Code 
CO 15 // 

fl 3 

I*? class A { } ; 

: : ? 
f ^ 

outfile Directive 

The outfile directive specifies the output file to write to 
for that section of the template. 

20 Syntax 

<outfile FILENAME="outf ile_name" MODE="_mode_"> 

section 

</outf ile> 

where, 

25 outfile_name = $macro_name$ | string 

_mode_ = append | new 
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Description 

When the outfile directive is encountered, the specified 
outf ile__name is opened with the specified mode, and the 
section of the template is written to that output file. 

5 Example 

Consider the following template definition: 

£j <_TDEBlock_> 

m <outfile FILENAME="$filename$" MODE="new"> 

10 // C++ generated code 

CO f oo ( ) ; 

<outfile FILENAME="d: \\log.dat" MODE="append"> <-- need 

£ to escape the backslash 

:i This is a log entry. 

U-J 

fij 15 </outfile> 



// End C++ generated code 

</outfile> 

</_TDEBlock_> 

If the macro filename is defined to be foo.cpp, the 
20 following is emitted to foo.cpp: 

// C++ generated code 
f oo ( ) ; 

// End C++ generated code 
25 The file d:\log.dat will contain the following: 

This is a log entry. 
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code Directive 

The code directive identifies a section of code to emit when 
the cname value is set. 

Syntax 

<code NAME= " cname " > 

section 

</code> 

A code section can also be declared with parameters, in 
which case the call directive must be used to emit it. 

<code NAME ="cname, paraml, param2, . .., param_n"> 

section 

</code> 

Description 

The code directive takes a single cname and emits the 
delimited section if cname is invoked. If cname is not set, 
the section is not emitted. Code sections are useful for 
reusing templates, or for overriding other code sections 
with the same name. When using the <scope> directive, code 
sections can also be invoked recursively. The terminating 
condition is implicitly defined by the model, that is, when 
the code section is invoked from within a <scope> section 
that will eventually not be reached. 

Examplel 

Consider the following template: 
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<_TDEBlock_> 
<code NAME ="C_FORM"> 
ma Hoc ( sizeof ( Fred) ) ; 
5 </code> 

<code NAME ="CPP_FORM"> 
Fred* pTemp = new Fred; 
</code> 

<call NAME ="CPP_FORM"/> 
10 return ok; 

</_TDEBlock_> 

The following is emitted: 

Fred* pTemp = new Fred; 
15 return ok; 



lU call directive 

; : 3 

J~ The call directive is -the only way of invoking code 

□ sections. (Recall that a code section can also be emitted as 

a macro, by enclosing its name with $. This only works for 
20 code sections with no parameters) . 

Syntax : 

<call NAME="codeName" MACROLIST="macrol macro2 . . . 
macro_n"/> 

All the arguments of the call directive (a code name 
25 followed by macro names) can be separated by commas. 



Example : 
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<_TDEBlock_> 
<code NAME="C, M, N"> 
M = $M$ 

<repeat MACRO="N"> 
5 N = $N$ 

</repeat> 
</code> 

<call NAME="C" MACROLIST="M, N"/> 
</_TDEBlock_> 

Ift 10 If macro M was defined to have value w foo" and N to have 
CPj two values, w bar'' and W BAR'' then the following is 

a £ emitted: 

CO 

lr% M = foo 

L 15 N = bar 

["1 

m N = BAR 



same line Directive 

Syntax 
<sameline> 
20 section 

</sameline> 



Description 

The sameline directive is used to put its contained section 
on a single output line. Basically, all the newline 
25 characters from the section are removed and what follows 
after </sameline> will start on a new line. 
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Examplel 

Consider the following template: 

<_TDEBlock_> 
<sameline> 
int f unc ( 

<repeat MACRO="PARMS | separate w , ' ,M > 

$PARMS$ 

</repeat> 



</sameline> 
</_TDEBlock_> 

When the template is parsed with PARMS containing values 
w int a' 1 and w char c 1 ', the 
following is emitted: 

int func(int a, char c) ; 

assert Directive 

Syntax 

<assert EXPRESSION="expr M /> 

expr= (expr logical-operator expr) 



(value cond value) 
($macro_name$) 
( ! expr) 

( ! $macro name? ) 



logical -operator 



= & I I 
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cond = == | != I < I > I <= I >= 
value = string 

Description 

The assertion directive is used to test a boolean 
expression. If this expression is evaluated to false, an 
assertion failure exception is thrown. 
Examplel 

Consider the following template: 

<__TDEBlock_> 

<def ine MACRO="macroA">Bird</def ine> 
<def ine MACRO="macroB">Bee</def ine> 
<sameline> 
int f unc ( 

<assert EXPRESSION="$macroA$ < $macroB$ M /> 
) ; 

</sameline> 
</_TDEBlock_> 

When the template is parsed nothing is emitted since Bird 
not a substring of Bee. Instead an assertion failure 
exception is thrown. 

has scope directive 

The hasscope directive is used to determine if a scope 
exists within the XML model. 

Syntax 

<has scope NAME= M sname"> 
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section 
</hasscope> 

Description 

The sname specifies the name of the scope. This directive 
5 does not navigate the XML model. If the scope name does 
exist the 'section 1 is emitted. 

Example 

Suppose the model defines an element "Class 11 which has two 

other embedded elements: 
s £ 10 <Class name="Set"> 
^ <Method name="add"> 

ip </Method> 
L <Method name="del"> 

CO </Method> 
15 </Class> 

When the part "Class 1 1 is generated, using the following 
template : 

<_TDEBlock_> 

20 class $name$ { <-- this $name$ is from the Class 

ob j ect 

<hasscope NAME="Method">- 
/^Starting Method Declaration*/ 
<scope NAME="Method"> 
25 void $name$(); 

</ scope> 
/*End of Method Declaration*/ 
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</hasscope> 
}; 

</_TDEBlock_> 

The following is emitted: 

5 

class Set { 

/^Starting Method Declaration*/ 
void add ( ) ; 
void del ( ) ; 
10 /*End of Method Declaration*/ 

} 

if has scope directive 

The ifhasscope directive behaves in the same manner as a 
hasscope directive followed by a scope directive. This 
15 directive first tests whether the scope name exists. If the 
scope name does exist the scope name is navigated. This 
directive may be used in conjunction with an else statement. 



Syntax 

20 <ifhasscope NAME="sname"> 
sectionA 
<else/> 
sectionB 
</if hasscope> 

25 Description 

The sname specifies the name of the scope 
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Example 

Suppose the model defines an element w Class' 1 which has two 
other embedded elements: 

5 <Class name="Set"> 

<Method name="add"> 
</Method> 

<Method name="del"> 
</Method> 
10 </Class> 

When the part "Class 1 1 is generated, using the following 
template : 



f 7t 



fl <_TDEBlock> 

^ 15 class $name$ { 

<ifhasscope NAME= "Method" > 
/^Starting Method Declaration*/ 

void $name$ ( ) ; 
/*End of Method Declaration*/ 
20 <else/> 

method was not there 
</if hasscope> 
}; 

</_TDEBlock_> 
25 The following is emitted: 
class Set { 
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/^Starting Method Declaration*/ 
void add ( ) ; 

/*End of Method Declaration*/ 

} 

5 Note only the first method is emitted. In order to emit the 
second method a second "ifhasscope" directive must be added 
to the template file. If it were not possible to scope to 
method, the else statement would have been executed. 

fj% if hasrepeatscope directive 

% 10 The if hasrepeatscope directive behaves in the same manner as 

CO a hasscope directive followed by a repeatscope 

^ directive . This directive first tests whether the scope name 

3^ exist. If the scope name does exist all children elements 

that matches the scope name are navigated. This directive 

fU 15 works in conjunction with the else statement. 

s . % 

□ Syntax 

<if hasrepeatscope NAME="sname"> 
sectionA 
<else/> 
20 sectionB 

</ if ha srepeat scope > 



Description 

The sname specifies the name of the scope 



Example 
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Suppose the model defines an element w Class !l which has' two 
other embedded elements: 



Id 



<Class name="Set"> 
5 <Method name="add"> 

</Method> 

<Method name="del"> 
</Method> 
</Class> 

10 When the part "Class 11 is generated, using the following 
template : 

<_TDEBlock> 

class $name$ { 
15 <ifhasrepeatscope NAME="Method"> 

/^Starting Method Declaration*/ 

void $name$ ( ) ; 
/*End of Method Declaration*/ 
<else/> 

20 no methods were found 

</if has repeat scope> 
}; 

</ TDEBlock > 



25 



The following is emitted: 

class Set { 

/^Starting Method Declaration*/ 
void add ( ) ; 
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void del ( ) ; 

/*End of Method Declaration*/ 



Note that in this example the 
5 if hasrepeatscope navigates to 
scope name. In this case the 



second method is emitted. The 
all elements that matches the 
scope name is "Method". 



Id 

Q 
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Modifying Existing DOM Trees 

Template files can be created to modify existing DOM trees 
associated with a domain model. There are several main 
operations that are defined to accomplish this task. Add an 
5 element , remove an element, scope to an element, update an 

attribute, update an element, add an attribute and remove an 
attribute . 



target scope directive 

The targetscope directive navigates an element that is part 
10 of an existing DOM tree associated with a domain model. 



Syntax 

g <targetscope NAME="sname" INDEX=_index_> 

section 
-g </targetscope> 

fi a 

;^ 15 where, 

sname = target scope name 
_index_ = integer value 
Description 

The sname specifies the name of the scope. The _index_ 
20 value specifies which element to navigate based on an index 
value. The default value is set to 0. Therefore, if there 
is more than one element that is found, the first element is 
scoped. 



Example 

25 Suppose the model defines an element w Class 11 which has two 
other embedded elements. This document is called class. xml. 
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<Classlist> 
<Class name="Set"> 
<Method name="add"> 
</Method> 
5 <Method name="del"> 
</Method> 
</Class> 
</Classlist> 

sQ 10 Also consider the following template: 

=p <?xml version="l . 0"?> 

il <!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 

S3 <_TDEBlock_ DOMTree="class . xml"> 

^ <targetscope NAME="Class"> 

CO 15 </targetscope> 
\fi </ TDEBlock > 



The mechanism will navigate to the Class element in the 
class. xml document. Note no emitted output is created since 
this directive just navigates the targeted XML document. In 
20 this case the targeted XML document is class. xml. 



addtarget scope directive 

The addtargetscope directive is used to insert an element 
into a DOM tree associated with a domain model. 



Syntax 

25 <addtargetscope NAME="sname" INDEX=_index_> 
where, 
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sname = target scope name 
_index_ = integer value 

Description 

The sname specifies the name of the scope. The _index_ 
value specifies where to insert the element. The default 
value of the index is set to 0. Therefore, the element that 
is added will become the first child element. If a -1 is 
specified as the index the element that is added will be the 
last child element. 

Example 

Suppose the model defines an element w Class' 1 which has two 
other embedded elements. Lets say that this document is 
called class. xml. 

<Classlist> 
<Class name="Set"> 
<Method name= M add"> 
</Method> 

<Method name="del"> 
</Method> 
</Class> 
</Classlist> 

Also consider the following template: 
<?xml version="l . 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd" > 
< TDEBlock DOMTree= f, class.xml"> 
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<targetscope NAME="Class"> 

<addtargetscope NAME="Method"> 

<addtar get scope NAME= "Argument l! X/addtargetscope> 

</addtargetscope> 
</targetscope> 
</_TDEBlock_> 

The result of applying the template is as follows: 

<ClassList> 

<Class name="Set"> 

<Method> 

<Argument/> 
</Method> 

<Method name= f, add lf > 
</Method> 

<Method name="del n > 
</Method> 
</Class> 
</Classlist> 

updatetargetscope directive 

The updatetargetscope directive is used to update an element 
of a DOM tree associated with a domain model. If the element 
does not exist it is inserted into the DOM tree. 

Syntax 

<updatetargetscope NAME= n sname" INDEX=_index_> 
where, 

sname = target scope name 
_index_ = integer value 
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Description 

The sname specifies the name of the scope. The default 
value of the index is set to 0. Therefore, the first 
element will be updated. The index value is only used when 
5 adding an element. 

Example: Simple target document update 

Suppose the model defines an element w Class 11 which has two 

other embedded elements. This document is called class. xml. 
CP <Class name="Set"> 

% 10 <Method name="add"> 
CO </Method> 

<Method name="del"> 
^ </Method> 

</Class> 

ru 15 

□ Also consider the following template: 

<?xml version="l. 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd n > 
<_TDEBlock_ DOMTree="class .xml"> 
20 <define MACRO=newMethodName>addNew</def ine> 

<targetscope NAME- "Met hod "> 

<updatetargetscope NAME="name" 
TYPE="ATTRIBUTE>$newMethodName$</addtargetscope> 

< /target scope> 

25 </ TDEBlock > 
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the result of applying the template is as follows: 

<Class name="Set"> 
<Method name="addNew M > 
</Method> 

<Method name="del"> 

</Method> 

</Class> 

Notice the name of the first method changes from "add" to 
"addNew" . 

remove tar get scope directive 

The removetargetscope directive is used to delete an element 
from a DOM tree associated with a domain model. 

Syntax 

<remove target scope NAME="sname" INDEX-_index_/> 
where, 

sname = target scope name 
_index_ = integer value 

Description 

The sname specifies the name of the scope. The _index_ 
value specifies which element to remove based on an index 
value. The default value is set to 0. Therefore, if there 
is more than one element, the first element is removed. If 
the index is set to -1 the last child element is removed. 

Example 
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Suppose the model defines an element w Class 1 1 which has two 
other embedded elements. Lets say that this document is 
called class. xml 



<Class name="Set"> 
5 <Method name="add n > 
</Method> 

<Method name= M del"> 
</Method> 
^ </Class> 

m 10 

*p Also consider the following template: 

;^ <?xml version="l. 0"?> 

5_ <!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 

m <_TDEBlock_ DOMTree=" class. xml"> 

FU 15 <removetarget scope NAME="Method" /> 

H </_TDEBlock_> 

the result of applying the template is as follows: 



<Class name="Set"> 
<Method name="del"> 
20 </Method> 
</Class> 

Note that the first method element was removed. Since no 
index was specified the default value for the index is 0. 



updatetargetdoctype directive 
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The updatetargetdoctype directive is used to update the 
! DOCTYPE element of a DOM tree associated with a domain 
model. If the element does not exist is it inserted into the 
DOM Tree. 



5 Syntax 

<updatetargetdoctype SYSTEM_URL="SYSTEM_URL" 
PUBLIC_NAME="DTD_NAME" PUBLIC JJRL=" DTDJJRL" 
ROOT_ELEMENT_NAME="root_element "> 
where, 

Eft 10 DTD_name = a name that identifies the dtd file 

= C DTD_URL = an absolute or relative url where the dtd file 

CO can be found 

f Z SYSTEM URL = an absolute or relative url where the dtd 

s file can be found 

15 root__element = the root element tag name 

3 ; n 

~ Description 

C3 The DTD_URL is an absolute or relative path where the dtd 

file can be found. The DTD_URL is used if one wants to 
specify a public dtd. This attribute should only be 
20 specified if a public dtd is being used. Similarly the 

SYSTEM_URL is also an absolute or relative path where the 
dtd file can be found. This should be specified if a system 
dtd is being used. The DTD_name is a identifier that 
identifies the dtd file and is used when specifing a public 
25 dtd file. The root_element is the name of the root element 
of the document. If the root_element is not specified the 
mechanism will search the target document and find the root 
element tag name. 
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Examplel: Adding a simple ! DOCTYPE element 
Consider the following template file: 

<?xml version="l . 0 M ?> 

<! DOCTYPE _TDEBlock_ SYSTEM "../../../.. /dtd/tde . dtd"> 
5 <_TDEBlock_> 

<updatetargetdoctype PUBLIC_NAME="Chemistry" 
PUBLIC_URL="http : //sunsite/unc . edu/public/chemistry . dtd" 
^ ROOT_ELEMENT_NAME="myroot "/> 

£H </ TDEBlock > 

IE 10 

fj the result of applying the template is as follows: 

^y 

- M <?xml version="l . 0" standalone= ff no"?> 

[3 <! DOCTYPE myroot PUBLIC "Chemistry" 

^ " http : //sunsite/unc . edu/public/chemistry . dtd" > 

iy 

^ 15 Example2: Adding a simple ! DOCTYPE element plus an element. 
Consider the following template: 
<?xml version="l . 0"?> 

<! DOCTYPE _TDEBlock_ SYSTEM "../../../.. /dtd/tde . dtd"> 
<_TDEBlock_> 

20 <updatetargetdoctype SYSTEM_URL="mydtd . dtd" 

ROOT_ELEMENT_NAME= " MyMembe r " / > 

<updatetarget scope NAME="MyMember"> 

This is the text for the new member 
</updatetargetscope> 
25 </ TDEBlock > 
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the result of applying the template is as follows: 



<?xml version="l . 0" standalone="no" ?> 
<!DOCTYPE MyMember SYSTEM "mydtd . dtd"> 
<My]Member/> 



5 Example3: Adding a simple ! DOCTYPE element after adding an 
element . 

Consider the following template: 
4f <?xml version="l . 0 M ?> 

m <! DOCTYPE _TDEBlock_ SYSTEM "../../../.. /dtd/tde . dtd"> 

10 <_TDEBlock_> 
CO <updatetargetscope NAME=" MyMember "> 

This is the text for the new member 
s </updatetargetscope> 

rg <updatetargetdoctype SYSTEM_URL="mydtd . dtd"/> 

fU 15 </ TDEBlock > 

3.3 
s : s 

o 

O the result of applying the template is as follows: 

<?xml version="l . 0" standalone="no"?> 
<! DOCTYPE MyMember SYSTEM "mydtd . dtd"> 
<MyMember> 

20 This is the text for the new member 

</MyMember> 

Note that since the root node already exists (ie MyMember is 
created) at the point where "updatetargetdoctype" is 
defined, the ROOT_ELEMENT attribute does not need to be 
25 specified. The mechanism will know that "MyMember 11 is the 



CA919990037US1 





3 . 3 



root element and fill in the appropriate information in the 
1D0CTYPE element. 

addat tribute directive 

The addattribute directive adds an attribute to an existing 
element . 

Syntax 

<addattribute NAME="attrname">attrbute value</addattribute> 
where, 

attrname = attribute name. 



Cy 10 Description 



The attrname specifies the name of the attribute. If the 
attribute already exits the attribute will not be added to 
the element. 



m Example 

P 15 Suppose the model defines an element w Class 1 1 which has two 
other embedded elements. This document is called class. xml. 

<Class name= n Set"> 
<Method name="add"> 
</Method> 
20 <Method name="del"> 
</Method> 
</Class> 

Also consider the following template: 
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<?xml version="l . 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 
<_TDEBlock_ DOMTree="class . xml"> 
<targetscope NAME="Class"> 
5 <addtargetscope NAME="Method"> 

<addattribute NAME="name M >newMethod</addattribute> 
</addtargetscope> 
</ target scope> 
</_TDEBlock_> 

10 the result of applying the template is as follows: 

<Class name="Set"> 
<Method name="newMethod"> 
</Method> 

<Method name="add"> 
ro 15 </Method> 
;t <Method name="del"> 

O </Method> 
</Class> 

20 updateattribute directive 

The updateattribute directive behaves in the same manner as 
the addattribute directive. 

Syntax 

<addattribute NAME="attrname">attrbute value</addattribute> 
25 where, 

attrname = attribute name. 
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Description 

The attrname specifies the name of the attribute. If the 
attribute already exists the attribute value will be updated 
with the value specified in this directive. 



5 Example 

Suppose the model defines an element w Class 11 which has two 
other embedded elements. This document is called class. xml. 

;~ <Class name="Set"> 

01 <Method name="add"> 

J 10 </Method> 
ffl <Method name="del"> 

</Method> 
^ </Class> 

15 Also consider the following template: 

C3 

□ <?xml version="l . 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 
<_TDEBlock_ DOMTree="class . xml"> 
<targetscope NAME="Class"> 
20 <addtargetscope NAME="Method"> 

<updateattribute NAME="name">newMethod</addattribute> 
</addtargetscope> 

<updat eat tribute NAME="name">NewSetClass</addattribute> 
</targetscope> 
25 </ TDEBlock > 



the result of applying the template is as follows: 
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<Class name="NewSetClass"> 
<Method name="newiy[ethod"> 
</Method> 

<Method name="add"> 
</Method> 

<Method name="del"> 

</Method> 

</Class> 

Note the first updateattribute directive adds an attribute 
named "newMethod" on the newly created method element. The 
second updateattribute directive updates the "name" 
attribute on the Class element. 

removeat tribute directive 

The removeattribute directive removes an attribute from an 
existing element. 

Syntax 

<removeat tribute NAME="attrname"/> 
where, 

attrname = target attribute name 
Description 

The attrname specifies the name of the attribute. 
Example 

Suppose the model defines an element w Class 11 which has two 
other embedded elements. This document is called class. xml. 
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<Class name="Set"> 
<Method name="add"> 
</Method> 

<Method name="del"> 
5 </Method> 
</Class> 

Also consider the following template: 

□ 

til <?xml version="l . 0"?> 

"£ 10 <!DOCTYPE _TDEBlock_ SYSTEM " dtd/tde . dtd"> 

CO <_TDEBlock_ DOMTree="class . xml"> 

r ~ <targetscope NAME= "Method" > 

= <removeattribute NAME="name"/> 

IS </targetscope> 

fU 15 </_TDEBlock_> 

C3 

□ the result of applying the template is as follows: 

<Class name="Set"> 
<Method> 
</Method> 
20 <Method name="del"> 
</Method> 
</Class> 

Note the "name" attribute on the first Method element was 
removed. 

25 
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addtext directive 

The addtext directive adds text to an existing element. 
Syntax 

<addtext INDEX="_index_">text content</addtext> 
5 where, 

__index_ = integer value 

Description 

C3 

=.jj The _index_ value specifies where to insert the text. The 

*L! default value of the index is set to 0. Therefore, the text 

C C 10 content that is added will become the first child element. 

v3 Example 

* fS% Suppose the model defines an element w Class 11 which has two 

ffi other embedded elements. This document is called class. xml. 

fU 

C3 <Class name="Set"> 

^ 15 <Method name="add"> 
</Method> 

<Method name="del"> 

</Method> 

</Class> 

20 

Also consider the following template: 
<?xml version="l. 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 
<_TDEBlock_ DOMTree="class . xml"> 
25 <targetscope NAME="Class"> 
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<addtext>This class is a collection of ob j ects</addtext> 
</targetscope> 
</_TDEBlock_> 

the result of applying the template is as follows: 

5 <Class name-" Set "> 

This class is a collection of objects 

<Method name="add"> 
" </Method> 
in <Method name= f? del"> 

5 10 </Method> 
CO </Class> 

* updatetext directive 

f| The updatetext directive behaves in the same manner as the 

fU 15 addtext directive. 

9 

^ Syntax 

<updatetext INDEX="_index_" >text content</updatetext> 
where, 

_index_ = integer value 

20 Description 

The _index_ value specifies which text content to update. 
The default value of the index is set to 0. Therefore, the 
text content that is updated will become the first child 
element. If no text content is found at the specified index 

25 it is added at the index specified. 
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Example 

Suppose the model defines an element "Class 11 which has two 
other embedded elements. This document is called class. xml. 

<Class name="Set"> 
5 This is a collection of objects 
<Method name="add"> 
</Method> 

<Method name= M del"> 
: a </Method> 
IH 10 </Class> 

Also consider the following template: 

s <?xml version="l . 0"?> 

Q 

CQ <!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 

^ 15 <_TDEBlock_ DOMTree="class.xml"> 

%y 

O <targetscope NAME="Class"> 

^ <targetscope NAME="Method !, > 

<updatetext>//This method adds an object to the 
col lection< /update text> 
20 </targetscope> 

<updatetext>//This is a collection of objects. Also known as 
a set of obj ects . </updatetext> 
</targetscope> 
</_TDEBlock_> 

25 the result of applying the template is as follows: 
<Class name="NewSetClass M > 
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//This is a collection of objects. Also known as a set of 
objects . 

<Method name= M add"> 

//This method adds an object to the collection 
5 </Method> 

<Method name="del"> 

</Method> 

</Class> 

Note the first updatetext directive adds text content to the 
10 first method element. The second updatetext directive 
updates text content associated with the Class element. 

remove text directive 

The removetext directive removes text content from an 
existing element. 



P 15 Syntax 

u <removetext INDEX="_index_" /> 

where, 

_index_ = integer value 
Description 

20 The _index_ value specifies which text content to remove. 

The default value of the index is set to 0. Therefore, the 
text content that is removed will be the first child 
element . 

Example 
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Suppose the model defines an element "Class 11 which has two 

other embedded elements. This document is called class. xml. 

<Class name="Set"> 

This is a collection of objects 

<Method name="add ,f > 

</Method> 

<Method name="del"> 

</Method> 

</Class> 

Also consider the following template: 



<?xml version="1.0"?> 
U ' <!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd" > 
~ < TDEBlock DOMTree="class . xml"> 

□ 15 <removetext/> 
}jj </_TDEBlock_> 

the result of applying the template is as follows: 



<Class name="Set"> 
<Method> 
20 </Method> 

<Method name="del"> 

</Method> 

</Class> 

Note the text content under the Class element was removed, 
25 hastargetscope directive 
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The hastargetscope directive behave in a similar manner as 
the hasscope directive. However, this directive applies to 
the targeted DOM tree. If the targeted DOM tree contains 
the scope name the section of code defined within this 
directive is parsed. 

Syntax 

<hastargetscope NAME="sname" INDEX=_index_> 
section 

</hastargetscope> 
where , 

sname = target scope name 
_index_ = integer value 

Description 

The sname specifies the name of the scope. The _index_ 
value specifies if the element at the index value exists. 
The default value is set to 0. 

Example 

Suppose the model defines an element w Class 11 which has two 
other embedded elements. This document is called class. xml. 
<Class name="Set"> 
<Method name="add"> 
</Method> 

<Method name= ,f del"> 

</Method> 

</Class> 

Also consider the following template: 
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<?xml version="l . 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 
<_TDEBlock_ DOMTree="class . xml"> 
<targetscope NAME="Class"> 
5 <hastargetscope NAME="NOElement " /> 

< r emo vet ar get scope NAME= "Method" /> 
</hastargetscope> 
< /target scope> 
£l </_TDEBlock_> 

in 

=p 10 this resulting DOM tree is as follows: 

M : <Class name="Set"> 

I s * <Method name-"add"> 

□ </Method> 

a ; 5 

fj] <Method name="del"> 

U 15 </Method> 

□ </Class> 

Note that no changes were made. Since the "NOElement " was 
not found in the targeted DOM tree everything within the 
hastargetscope does not get processed. 

20 repeattargetscope directive 

The repeattargetscope directive behaves in a similar manner 
as the repeatscope directive. However, this directive 
applies to the targeted DOM tree. The repeattargetscope 
iterates over a list of child elements. 
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Syntax 

<repeat target scope NAME="sname"> 
section 

</repeattargetscope> 
5 where, 

sname = target scope name 

Description 

m The sname specifies the name of the scope, 

"ja Example 

*P 10 Suppose the model defines an element "Class 1 1 which has two 

|T other embedded elements. This document is called class. xml. 

& <Class name="Set"> 

m <Method name="add"> 

CO </Method> 

ru 

j. 3 15 <Method name="del"> 

O </Method> 

13 

</Class> 

Also consider the following template: 

20 <?xml version="l. 0"?> 

<!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 

<_TDEBlock_ DOMTree="class . xml"> 

<repeattargetscope NAME="Method"> 

<addattribute NAME="type">void</addattribute> 
25 < /repeat targetscope> 

</ TDEBlock > 
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this resulting DOM tree is as follows: 

<Class name= M Set"> 

<Method name="add" type="void"> 

</Method> 

5 <Method name="del" type="void"> 
</Method> 
</Class> 

S3 if hasrepeat target scope directive 

"% 10 The if hasrepeattargetscope directive behaves in a similar 

=C manner as the if hasrepeatscope directive. However, this 

ED 

^ directive applies to the targeted DOM tree. The 

Uj if hasrepeattargetscope directive iterates over a list of 

r=§ child elements. If a child list does not exist the section 

CO 15 of text between the directive does not get processed. This 
directive may also be used with the else statement. 



Syntax 

<if hasrepeattargetscope NAME=" sname "> 
sectionA 
20 <else/> 
sectionB 

</if hasrepeat tar getscope> 
where, 

sname = target scope name 

25 Description 

The sname specifies the name of the scope, 
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Example 

Suppose the model defines a list of elements. This 
document is called element. xml. 
<ElementList> 
5 <Element index="l"/> 
<Element index="2"/> 
<Element index="3"/> 
<Element index="4"/> 
<Element index="5"/> 
q 10 <Element index="6"/> 

^0 <Element index="7"/> 

in 

p <Element index="8"/> 

S F </ElementList> 

CO 

^ 15 Also consider the following template: 



13 



<?xml version="l. 0"?> 



CO 

ffj 

III <!DOCTYPE TDEBlock SYSTEM "dtd/tde . dtd"> 



<_TDEBlock_ DOMTree="element . xml"> 

<if ha srepeattar get scope NAME="NOElement"> 
20 <addattribute NAME= !, name">ElementName</addattribute> 

<else/> 

<addtarget scope NAME="NOElement"/> 
</if hasrepeattargetscope> 
</_TDEBlock_> 

25 this resulting DOM tree is as follows: 



<ElementList> 
<NOElement> 
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<Element index="l"/> 
<Element index="2"/> 
<Element index= M 3 " /> 
<Element index="4"/> 
5 <Element index="5"/> 
<Element index="6"/> 
<Element index= ,f 7 M /> 
<Element index= !f 8 M /> 
</ElementList> 

iQj 
EF1 

10 Note the DOM tree would not change. The 1 addattribute 1 does 

B H not get processed since the ' if hasrepeattargetscope 1 is 

|^ trying to scope to an element type called "NOElement " that 

^ does not exist. The else statement is then processed and a 

p new element is added. 

CO 

ly 15 if hastargetscope directive 

It The if hastargetscope directive behaves in a similar manner 

as the ifhasscope directive. However, this directive 
applies to the targeted DOM tree. If the targeted DOM tree 
contains the scope name the section of code defined within 
20 this directive is scoped. The else directive maybe used here 
as well. 

Syntax 

<ifhastargetscope NAME= ,f sname" INDEX=_index_> 
sectionA 
25 <else/> 
sectionB 

</if has target scope> 
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where, 

sname = target scope name 
index = integer value 



Description 

5 The sname specifies the name of the scope. The _index_ 
value specifies if the element at the index value exists. 
The default value is set to 0. 



Example 

Suppose the model defines an element "Class' 1 which has two 
10 other embedded elements. This document is called class. xml. 
<Class name= M Set"> 
<Method name="add M > 
</Method> 

<Method name="del"> 
15 </Method> 
</Class> 

Also consider the following template: 



<?xml version="l . 0"?> 
20 <!DOCTYPE _TDEBlock_ SYSTEM "dtd/tde . dtd"> 
<_TDEBlock_ DOMTree="class . xml"> 
<targetscope NAME="Class"> 

<if has target scope NAiyiE= "Method" /> 

<addattribute NAME="type">void</addattribute> 
25 <else/> 

<addtarget scope NAME= "Method" /> 
</if has tar gets cope> 
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<i f hast arget scope NAME="NoMethod"/> 

<addtar get scope NAME=" Element "></addt arget scope> 
<else/> 

<addtarget scope NAME="newMethod" /> 
</if hastargetscope> 
</ target scope> 
</_TDEBlock_> 

this resulting DOM tree is as follows: 

<Class name="Set"> 

<Method name="add" type="void"> 

</Method> 

<Method name="del"> 

</Method> 

<newmethod> 

</newmethod> 

</Class> 

Note that the attribute was added to the first method. No 
element changes were made. Since the "NOMethod" was not 
found in the targeted DOM tree, the else statement gets 
processed and a new element is added called newmethod. 

crea tea lias directive 

The createalias directive is used to define logical roots. 
These logical roots acts as pointers on a DOM tree. 

Syntax 

<createalias ALIASNAME="alias" ALIASPATH=" sname" /> 
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where, 

sname = target scope name 

alias = the alias name that represents the logical root 
Description 

The sname specifies the name of the scope. The alias 
represents the logical root. Using alias names simplifies 
navigating a DOM tree. Furthermore, using alias names can 
make the template more readable. Alias names are globally 
visible just like macros. 

Example 

Consider the following source XML document: 
< Package name=MyPackage> 
<ClassList> 

<Class name=HondaCar> 

<Method name=addHondaCar> 
</Method> 

<Method name=removeHondaCar> 
</Method> 
</Class> 

<Class name=FordCar> 

<Method name=addFordCar> 
</Method> 

<Method name=removeFordCar> 
</Method> 
</Class> 
</ClassList> 
</Package> 
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Now consider the following template file: 

<_TDEBlock_> 

<createalias ALIASNAME="HondaClass" 
ALIASPATH="ClassList//Class [0] "/> 

<scope NAME="ClassList//Class [1] "> 

<createalias ALIASNAME=" FordAddCarMethod" 
ALIAS PATH= "Method [ 0 ] "/> 

</scope> 

<scope NAME="HondaClass"> 

<repeatscope NAME="Method"> 
$name$ 
</repeatscope> 
</scope> 

<scope NAME="ClassList//Class [1] "> 
$ FordAddCarMethod/ /name$ 
</scope> 
</_TDEBlock_> 

The resulting generated output is as follows: 
addHondaCar 
removeHondaCar 
addFordCar 

The above example defines two alias names. The alias name 
"HondaClass" defines a logical root that references the 
first class element in the DOM tree. The second alias, 
"FordAddCarMethod", references the first method under the 
second class. As one can see alias names can be used to 
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jump throughout a DOM tree. An alias name can be 
overridden . 



i y 
§ - % 
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Text Content 

Description 

An XML document consists of child elements that may or may 
not have a text content. The text content of a child 
element is represented by a macro called $TEXT$. Consider 
the following XML document. 
<class> 

<Name>Foo</Name> 
</class> 

A template file can access the text contents of the 'Name 1 
element as follows (see Scoping Directive Section): 

<_TDEBlock_> 

<scope NAME="class"> 

<scope NAME= "Name " > 
$TEXT$ 

</scope> 
</scope> 
</_TDEBlock_> 

The resulting emitted code would be: 
Foo 

The template file can get complicated if numerous text 
contents need to be accessed. A scoping rule for each 
sibling would need to be implemented. In order to improve 
usability a scoping operator can be used. This scoping 
operator is defined as V/ 1 . Therefore the above template 
file can be rewritten as follows: 
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<_TDEBlock> 

<scope NAME="class"> 

$Name//Text$ 
</scope> 
<__TDEBlock_> 

Positional navigation that is used in scoping can also be 
used with macros. This is useful in cases where there 
exists elements of the same type. This is illustrated in 
the following example: 
<class> 

<Name>Foo</Name> 

<Name>Foo2</Name> 
</class> 

The following template illustrates positional navigation. 

<_TDEBlock_> 

<scope NAME="Class"> 

$Name[2] //TEXT$ 

$Name[l] //TEXT$ 
</scope> 
</__TDEBlock_> 

The emitted code is as follows: 

Foo2 
Foo 
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If no index is given the first sibling that matches the 
macro is used. Similarly, each element can has a list of 
text contents. Consider the following XML document. 



<class> 



Extra Textl 



<Name>Foo</Name> 



Extra Text2 



<Method>MyMethod</Method> 



Extra Text3 



O 10 </class> 

»5 Each text content under an element is given an index value. 

SSI 

This index identifies each text content so that positional 
navigation can be used to navigate the text content list. 

*~ This is illustrated in the following template file. 

O 15 < TDEBlock > 



20 



<scope NAME="class"> 
Name=$Name//Text$ 
First Text =$Text[l]$ 
Second Text =$Text[2]$ 
Third Text =$Text[3]$ 



</scope> 



</ TDEBlock > 



The resulting output is emitted: 



Name=Foo 



25 



First Text =Extra Textl 



Second Text =Extra Text2 



Third Text =Extra Text3 
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If no index is given all text content within the element is 
appended together. 



in 



16 

ru 
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Children Navigation 

The mechanism provides means to navigate an elements 
children nodes generically. For example consider the 
following tree: 

Elementl 



O 

10 I 



I I 

Element2 Element3 



u I I I I 

\Q Element4 Elements Element6 Element7 

One might want to navigate to all the end nodes of the tree 
; s | 15 without the hassle of knowing Element2 and Element3. Or 
□ one might want to repeat on all the children nodes of an 

element. Typically, in order to process Element2 and 
Element3 a separate scoping directive would have to be 
written for each element. For example consider the 
20 following template file: 
<_TDEBlock_> 

<scope NAME="Element2"> 

$Name$ 
</scope> 

25 <scope NAME="Element3"> 

$Name$ 
</scope> 
</ TDEBlock > 



CA919990037US1 



Note for both Elements we are extracting the Name attribute. 
The template file can be huge if there were more children 
elements. Just like there is a predefined string to 
represent a parent for an element (ie. "..") there should be 
a predefined string to represent the children elements (ie. 
_TDECHILDREN_) . With this in mind the above template can 
be rewritten as follows: 
<_TDEBlock_> 

<repeatscope NAME="_TDECHILDREN_"> 
$Name$ 
</ repeat scope> 
<_TDEBlock_> 

One can also navigate to a specific child node based on 
index. For example consider the following template file: 
<_TDEBlock_> 

<scope NAME="_TDECHILDREN_ [ 1 ] "> 
$Name$ 
</scope> 
< TDEBlock > 
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Tag Name Content 

Description 

The mechanism provides a predefined macro to get the tag 
name of an element. This macro is called $_TDETAGNAME_$ . 
5 Consider the following XML document. 
<class> 

<Name>Foo</Name> 
</class> 

o 

,g A template file can access the tag name content of the 

10 ! Name f element as follows: 
T < TDEBlock > 

® <scope NAME= "class 11 > 

[r% <scope NAME="Name"> 

^ $_TDETAGNAME_$ 
Cg 15 </scope> 
</scope> 
</_TDEBlock_> 

The resulting emitted code would be: 



Name 



20 Consider a list of students that each have a list of marks 
as represented by the following XML document: 
<student_list> 
<student> 

<id>166443</id> 
25 <name>Sean Watt</name> 

<marks> 
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<biology>63</biology> 
<math>75</math> 
<chemistry>62</chemistry> 
<physics>66</physics> 
5 <english>7 8</english> 

</marks> 
</student> 
<student> 

<id>4457833</id> 
10 <name>Whitney Lee</name> 

<marks> 

<biology>88</biology> 
<math>78</math> 
<chemistry>82</chemistry> 
%D 15 , <physics>95</physics> 

<english>8K/english> 
CO </marks> 

ru 

i.a </student> 

□ <student> 

" 20 <id>7641133</id> 

<name>Bob Barney</name> 

<marks> 

<biology>7 3</biology> 
<math>92</math> 
25 <chemistry>8 3</chemistry> 

<physics>7 6</physics> 
<english>8 3</english> 
</marks> 
</student> 
30 </student list> 
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Suppose all the biology marks and math marks are desired. 
We can write the following template to extract this 
information from the above document: 

<_TDEBlock_> 

<scope NAME="student_list"> 

< repeat scope NAME= " student "> 
<scope NAME="marks"> 
<repeatscope NAME="_TDECHILDREN_"> 
<if 

EXPRESSION=" ( ( $_TDETAGNAME_$— &quot ; biology&quot ; ) | 
( $_TDETAGNAME_$=-&quot ;math&quot ; ) ) "> 

$TEXT$ 

</if> 
< /repeat scope> 
</scope> 
</repeatscope> 
</scope> 
</_TDEBlock_> 

The above template file navigates down to the mark element 
and then navigates through all the children elements under 
the mark element. An if statement matches the tag name of 
each child element. If any of the child elements are equal 
to "math" or "biology" the text content of the child element 
is extracted. 

The resulting emitted code is as follows: 
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63 
75 
88 
78 
73 
92 



Comments 

Comments help makes the template files easier to read. They 
do not get emitted in the output file. A blank line on the 
10 other hand will get emitted in the output file. 

Syntax 

< ! -- comment --> 
Example 

The following are some comment lines in the template file. 
15 <!-- 

This is a template file 
— > 
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